A question for mirmir on pfsense vpn

Discussion in 'privacy technology' started by lapibaru, May 16, 2014.

Thread Status:
Not open for further replies.
  1. lapibaru

    lapibaru Registered Member

    Joined:
    May 16, 2014
    Posts:
    13
    Hi mirmir, thank you for amazing tutorials! I am a newbie, but I followed your guides and learned a lot.
    I've been struggling for a few days now, I really need your help.:thumbd:

    I use virtualbox. I installed a pfsense VM, and guest in a linux VM. Network settings setup as you described. Linux network manager updated.

    I'm stuck with not getting internet connection through pfsense VM on the linux VM. I followed your guide for creating pfsense VM. I did everything you wrote, except for vpn client setup I used TCP and port 443 for sekis. Interface - WAN. Added:
    remote-cert-tls server;verb 5
    redirect-gateway def1;
    to advanced.
    Envryption...as you said. LZO-yes.
    I added the sekis ca.crt in cas(private key left blank), and client.crt and client.key in certificates. For all three I copy pasted like this: -----BEGIN CERTIFICATE-----....394@%532552335@5673697.....-----END CERTIFICATE-----. I tried these openvpn certificates on other linux VM, they work. I also used opendns servers everywhere throghout the pfsense webconfiguration.(I know that's bad, I will put different ones when I make this work). pfsense VM is nated to host which uses 3g modem - could this be a problem? Internet works in other linux VMs when nated to host. Linux vm is connected to pfsense's internal.

    So I run webconfigurator on this linux VM. Followed your instructions, configured everything as you described.
    When I connect to internet on the host and reboot the pfsense VM I get the ovpnc1 IP.
    In status-dashboard wan lan and opt1 are all green and have IP addresses. Wan ipv4 is set to DHCP. LAN is static. opt1 has the IP from the ovpnc1 in pfsense VM. It ends in /32. And wan and lan IPs end with /24. (don't know if this matters)

    Satus-openvpn is down
    down 0 Service not running? Unable to contact daemon 0 0

    I then restart the linux VM. Login back to webconfigurator, but it's the same.
    I click start openvpn service and then I get:

    apinger Gateway Monitoring Daemon status Running
    dhcpd DHCP Service status Running
    ntpd NTP clock sync status Running
    openvpn OpenVPN client: sekis status Running

    I click restart service for openvpn.

    in the log for openvpn in the end it shows:
    Initialization Sequence Completed

    But when I go back to status: openvpn it's down again.

    I then reboot the pfsense VM .........and now it's up!
    Looks like I need to restart linux VM, and then pfsense VM.

    Well, now I click on the log and here's what I get:
    last 5 lines:
    Initialization Sequence Completed
    MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
    MANAGEMENT: CMD 'state 1'
    MANAGEMENT: CMD 'status 2'
    MANAGEMENT: Client disconnected

    then I click restart openvpn service:
    apinger Gateway Monitoring Daemon status Running
    dhcpd DHCP Service status Running
    ntpd NTP clock sync status Running
    openvpn OpenVPN client: sekis status Running

    but NO internet connection :)

    What could it be?

    By the way could time sync be a problem? How should I set up time for host and guest as a permanent solution? (For this experiment I set the same time for guest and host.)

    If this is so complicated...I will give up. I am too noob for this
    Would it be much less secure if I run openvpn clients on host and guest and use pfsense just as a router and a firewall?
     
  2. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    Have you added and enabled the openvpn interface? Even though pfSense shows the VPN as connected, VMs on its LAN won't have Internet connectivity until you have added and enabled the openvpn interface, and rebooted. For security, you also want to delete the outbound NAT rules for WAN, and restrict outbound traffic from LAN to the openvpn gateway.

    Don't worry about the "MANAGEMENT: ..." messages. They don't affect connectivity through the VPN.

    If you just follow the instructions exactly, it will work :)
     
  3. lapibaru

    lapibaru Registered Member

    Joined:
    May 16, 2014
    Posts:
    13
    Thank you for the reply!

    Ok, so I deleted everything, and started once again, from scratch.
    Installed pfsense...And the linux VM. This time set it up exactly as in the guide.
    After 4 hours I finally got it all green and running, but internet doesn't work on the linux VM. (It did work in the beginning before configuring)

    I used skiss. Different server. I tried it it works. and TCP 443. Everything else as in the guide.

    What do you mean by "added and enabled openvpn interface"?
    If you refer to this:
    "Now go to Interfaces: Assign network ports, hit the + icon, and hit Save to add OPT1. Then go to Interfaces: OPT1, enable it, rename it as SKISS or whatever, save and apply changes. In Firewall: NAT: Outbound, select Manual Outbound NAT rule generation, save, and then apply changes. In the same tab, check (select) the three rules (for ISAKMP, LAN and localhost) with WAN as interface, delete them using the x button at the lower right, and then apply changes. Don’t mess with the rules with SKISS (or whatever you called it) as interface"

    I did all that. Assigned SEKISS to the interface:assign. And enabled and saved it. But I don't understand what you mean by your last sentence because after deleting those 3 interfaces there is nothing under Firewall:NAT:eek:utbound ?

    Client TCP is up. In the log: Initialization Sequence Completed.
    First I tried the DNS from the PUSH:...line from the log. Then I changed to openDNS servers which I know that they work. (under services:dhcp server)

    In firewall:rules. After I did this:

    "In Firewall: Rules: LAN, edit the existing rule Default allow LAN to any rule. Using the Gateway toggle in the lower Advanced features section, select SKISS as gateway. Rename the rule as Allow LAN to any rule via SKISS, save, and then apply changes. In the rule list, it should look like * LAN net * * * SKISS none.

    Create exactly the same rule Allow LAN to any rule via SKISS in both Firewall: Rules: WAN and Firewall: Rules: OpenVPN. Save and apply changes before leaving each tab. Both should look like * LAN net * * * SKISS none in the list.

    In Firewall: Rules: SKISS, create a rule that passes everything from anywhere to any rule on the default gateway. Don’t change anything in Advanced features. Name it Allow everything to any rule, save and apply changes. It should look like * * * * * * none in the list."

    When I go to WAN and create exactly the same rule they all appear under firewall:rules:LAN ?
    And nothing under WAN and OpenVPN? Is that how it should be?
    IPv4 * LAN net * * * OPT1_VPNV4 none
    IPv4 * LAN net * * * OPT1_VPNV4 none
    IPv4 * LAN net * * * OPT1_VPNV4 none

    So Status: OpenVPN is up, in the log the last line is: Initialization Sequence Completed, status :dashboard - all green and have ip addresses. Rebooted pfsense VM - no internet. Rebooted - linux VM - no internet. ping 4.2.2.2 also no response.

    I don't get it...Oh yes, and by the way:
    WAN is (DHCP) and not static. Is that a mistake?

    Also, I removed from advanced remote-cert-tls server;verb 5
    because it goes up and then down with this message:
    Initialization Sequence Completed
    MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
    MANAGEMENT: CMD 'state 1'
    MANAGEMENT: CMD 'status 2
    MANAGEMENT: Client disconnected

    without that line in advanced it's up without disconnecting?

    What does this all mean? Is my vpn setup working and connecting to the server but something else is a problem?
     
  4. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    You should have Internet connectivity on the Linux VM through a new pfSense VM that hasn't yet been configured. And that's what I think you said.

    Sometimes, after you've configured pfSense, it doesn't work properly until you reboot it. Also, sometimes it's necessary to reload the eth0 configuration in the Linux VM by clicking the Network Manager icon and selecting "Wired connection 1".
    Yes, that's what I mean.
    That's not good :(

    If there are no outbound NAT rules in your pfSense VM, that's why it's not working.

    Start over again with a fresh pfSense VM. When you get to the Outbound NAT step, if there are just three rules, all with WAN as interface, don't delete them. Rather, edit each one, and change the interface from WAN to SEKISS. Maybe the latest pfSense release has changed this behavior. I'll look into that.
    Either should work.
    I don't know why the "Allow LAN to any rule via S[E]KISS" rules in the WAN and OpenVPN tabs are showing up in the LAN tab. But actually, it turns out that only the "Allow LAN to any rule via SKISS" rule in LAN is necessary, because packets from LAN won't show up elsewhere needing routing. However, having the rules in the WAN and OpenVPN tabs doesn't hurt.

    Also it turns out that the "Allow everything" rule in the S[E]KISS tab also isn't necessary. I've been meaning to update the guide. But again, having that rule won't hurt, because the LAN rules don't allow new incoming connections.
    As noted above, I suspect that it's the lack of outbound NAT rules that has broken your pfSense VM.
    No, that's fine. WAN should be DHCP (from the VirtualBox internal DHCP server) and LAN should be static. You don't want to assign a gateway for either. pfSense will use a default gateway for WAN.
    I'm pretty sure that it's removing "verb 5" that eliminates the "MANAGEMENT" lines from the connection log. That's just because "MANAGEMENT" lines aren't shown at logging level "verb 5" ("verb" being short for "verbosity"). But you can test that. The option "remote-cert-tls server" helps protect against MitM by fake servers, and it's poorly documented.
    I suspect that it's the lack of outbound NAT rules that has broken your pfSense VM. I hope that's it, because it would be the simplest answer.
     
  5. lapibaru

    lapibaru Registered Member

    Joined:
    May 16, 2014
    Posts:
    13
    It's working! :)

    You were right. I didn't want to do this ALL over again so I just went to firewall:NAT and changed to automatic and saved and applied. Then I changed to manual and the 3 WANs were there! I changed them to SEKISS and it works! Tried with different DNS in Services:dhcp servers and it works. Tested with grc and it's ok. By the way, when I put back the ..;verb 5 in advanced the MANAGEMENT thing appears in the log once again, but internet and vpn still work.

    Do I need to change anything else in firewall:NAT except WAN to SEKISS?

    And the most important question - how do I set this up to work just like what adrelanos does?
    I don't want it to leak the IP from host when VPN drops... :(
     
  6. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    I'm very glad to hear that :)

    I'm sure that setting up your next pfSense VM will go much faster. The major problem is figuring out which options from the OpenVPN config file to put in the Advanced box of the pfSense client setup. And there's an additional complication: pfSense may reject some options, and not implement them. But it doesn't tell you. You can see what it's actually using by using "Diagnostics: Edit file" and browsing "/var/etc/openvpn/client1.conf". But don't edit that file directly ;)
    That's very good to know. I'll add that to the guide.
    :)
    Yes. Put back the "remote-cert-tls server" option as well, if it's present in the client.conf that you're working from. VPN providers may tweak their server setups in various ways, and your client needs to match.
    No, that's all that's needed.

    And in "Firewall: Rules" you only need to change the default LAN rule. None of the rules in WAN, SEKISS or OpenVPN are needed. I'm going to revise the guide today.
    I don't believe that any other changes are necessary to block leaks. However, there are some optional tweaks that I've been meaning to add to the guide. They come from a conversation on Wilders, but I've forgotten who to credit :( Please comment or PM me if you remember.

    There are three straightforward tweaks. In "System: Routing: Gateways", edit the SEKISS gateway. Check "Default Gateway" to set, save, and then apply changes. In "System: General Setup", set the gateway for all DNS servers listed as WAN (necessary because VPN is now default gateway). And in "System: Advanced: Miscellaneous: Gateway Monitoring", check "Skip Rules When Gateway is Down" to set, and save.

    By default, all outbound traffic is allowed on WAN. Restricting outbound traffic on WAN requires the use of aliases, because there can be multiple values, which are specified by hostname or IP address. Aliases are needed for three groups: 1) the DNS server IPs specified in "System: General Setup"; 2) the pfSense NTP server hostname specified in "System: General Setup"; and 3) the OpenVPN server hostname or IP specified in "OpenVPN: Client". For example:
    Code:
    ......................................................
    Name    Values                  Description
    dnssvr  1.2.3.4 5.6.7.8 ...     DNS server IPs
    ntpsvr  0.pfsense.pool.ntp.org  pfSense NTP server
    vpnsvr  vpn.entry.server.net    OpenVPN server (or IP)
    ......................................................
    In "Firewall: Rules: WAN", you add rules to pass outbound traffic to needed remote hosts, and then a final rule to block everything else. For example:
    Code:
    .............................................................................................
    Action  Proto    Source       Port  Destination  Port  Gateway  Queue  Description
    pass    TCP/UDP  WAN address  *     dnssvr       *     *        none   Allow to DNS server(s)
    pass    UDP      WAN address  *     ntpsvrs      *     *        none   Allow to NTP server
    pass    UDP      WAN address  *     vpnsvr       *     *        none   Allow to to VPN server
    block   *        WAN address  *     *            *     *        none   Block everything else
    .............................................................................................
    Edit: It was machan188 who suggested many of the above tweaks, in this thread: https://www.wilderssecurity.com/threads/can-you-trust-your-vpn-provider….354109/page-7#post-2360070
     
    Last edited: May 26, 2014
  7. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
  8. lapibaru

    lapibaru Registered Member

    Joined:
    May 16, 2014
    Posts:
    13
    Well thank you very much for your unselfish help mirmir!

    I made a completely new configuration from scratch following your updated part6. It all works! ;)

    The only thing I couldn't do is the last part, because when I go to Firewall:aliases:IP and click + to add a new alias there is nowhere to type in Values. Just name and description. I use pfsense 2.1.3
     
  9. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    I'm very glad to hear that :) Thanks for persisting.

    The latest release that I've used is the 2.1 release. In "Firewall: Aliases: Edit", I see four "fields": "Name", "Description", "Type" and "Host(s)". To enter hosts, you hit the "+" icon. You can enter either IP addresses or "fully qualified domain names". I'll add the bit about hitting the "+" icon.
     
  10. lapibaru

    lapibaru Registered Member

    Joined:
    May 16, 2014
    Posts:
    13
    Riiight...got it now. Values are actually (THE) IP addresses. All good.

    Looking forward to your other guides and future updates. Peace! ;)
     
  11. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    Yes, but they can also be hostnames, as for the NTP server that pfSense uses. When pfSense resolves that hostname, it gets the nearest 3-5 IP addresses. Using fixed IP addresses there could leak information.
    Thanks :)
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.