Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    OpenVPN tunnel issues & questions (is it the routing?)

    OpenVPN
    2
    4
    3010
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      SpaceBass last edited by

      Hey folks,

      I originally posted this in the 2.0 beta forum. Since then it has occurred to me that this has more to do with OpenVPN fundamentals than the beta so I thought I'd cross-post it here (hope that is ok).

      I am still successful at getting the tunnel to open (I think) but routing is proving to be a challenge still… As always, I'm very appreciative of everyone's time and willingness to offer tips and suggestions.


      I've spent the last 24 hours learning a whole lot about OpenVPN, routing and PFsense 2.0. The bad news is that rapid education means I'm still only one step shy of a total novice. However, I think I've found a few bugs - or at least opportunities to learn more.

      For the last 18 months or so, I have been using an IPsec tunnel for site-to-site b/t two PFsense boxes. However, I only have one WAN IP these days and I need to forward those IPsec ports to an internal L2TP server. I like OpenVPN and have been using it for road warriors and so it seemed like a good fit for the site-to-site tunnel (particularly if I can one day get layer 2 tunneling through dev tap).

      My first question - what is the appropriate way to set up a peer-to-peer (ptp)? Are they both clients? Is one a server and one a client? Are they both servers? None of those combinations seemed to produce a openVPN conf file that looked like what I would expect for a ptp tunnel.

      Secondly - there appears to be a bug related to using PSKs. That setting does not appear to be sticky in the client screens - no matter what, the config reverts to SSL/TLS. I understand the security ramifications of using a PSK, but for basic testing its much easier to troubleshoot.

      Third - do I need to create interfaces for the OpenVPN virtual adapters? I've noticed they will show up regardless, so I'd prefer not to create them (its just another layer of complexity)...but I have tried both ways.

      Finally - I've been able to edit the conf files in /var/etc/openvpn manually and finally got a tunnel started last night. However, I cannot seem to get anything to route at all. I have tried manually assigning the routes with mixed results. Usually I cannot ping either side of the tunnel, on occasion it does not just time out, it errors our in a strange way (see below)

      As a note - what I am calling the "remote" machine below is behind another router. Its an any/any setup with a static public IP,but it was the only way the telco could set up the wonky T-1 ... the result is that the remote PFsense box has a bogon address for its WAN.
      NOTE: I have deleted the configs that were here b/c they were so broken. I did not want to confuse anyone doing a search in the future. See below for the progress of this setup

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        I didn't catch you on IRC again, so I'll reply here.

        Two things:
        #1: Be sure you have added firewall rules for OpenVPN on your 2.0 system (Firewall > Rules, OpenVPN tab)
        #2: See the new FAQ entry I just added:
        http://doc.pfsense.org/index.php/Why_can%27t_I_ping_some_OpenVPN_adapter_addresses%3F

        In my test setup, I was able to reach a subnet behind my 2.0 test system, even though I was not able to ping the OpenVPN adapter addresses.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • S
          SpaceBass last edited by

          Thanks everyone, particularly Jim-P in IRC…
          made lots of progress
          from my 2.0 beta thread


          As indicated above, I've had some progress ... its still not working full, but I hope there can be some back scratching here
          Glad to be a part of testing 2.0 but could also use some basic OpenVPN help

          The config below creates a successful tunnel between two PFsense 2.0 beta boxes. From each PFsense box, I can ping resources on the other network. However, network resources cannot ping across the VPN. <--thats where I could use some help  ;D

          I have also added comments in the code below where the GUI produced something different or did not produce anything at all

          Server Config
          /var/etc/openvpn/server1.conf

          # cat server1.conf
          dev ovpns1
          dev-type tun
          dev-node /dev/tun1
          writepid /var/run/openvpn_server1.pid
          #user nobody
          #group nobody
          daemon
          keepalive 10 60
          ping-timer-rem
          persist-tun
          persist-key
          proto udp
          mode server  #not inserted by the GUI, but needed
          cipher AES-256-CBC
          client-config-dir /var/etc/openvpn-csc   #not inserted by GUI, but critical - specifies where to look for client configs
          up /etc/rc.filter_configure
          down /etc/rc.filter_configure
          local 96.253.96.54
          tls-server
          #ifconfig 192.168.123.1 192.168.123.2  #inserted by gui, but I think this wrong for ptp setups 
          server  192.168.123.0 255.255.255.0   #not inserted by gui but key to making my setup work
          lport 1194
          management 127.0.0.1 1194
          max-clients 250
          push "route 10.1.1.0 255.255.255.0"
          push "route 10.1.5.0 255.255.255.0"   #entered into the gui, but was not in conf files, had to manually add
          route 10.1.5.0 255.255.255.0           #missing in GUI, required for ptp setup
          ca /var/etc/openvpn/server1.ca
          cert /var/etc/openvpn/server1.cert
          key /var/etc/openvpn/server1.key
          dh /etc/dh-parameters.1024
          comp-lzo
          client-to-client             #checked the box in GUI, did not add to conf, had to manually add it
          verb 3              #this is the default for PFsense, I added the line so I could increase to 6 or 9 for testing
          
          

          Client specific code in /var/etc/openvpn-csc/

          # cat ../openvpn-csc/lynchburgclient 
          iroute 10.1.5.0 255.255.255.0  #required for ptp, no place in GUI to add this
          ifconfig-push 192.168.123.5 192.168.123.6 #required for ptp, no place in GUI to add this
          client-to-client  #required for ptp, no place in GUI to add this
          
          

          CLIENT (lynchburgclient)
          /var/etc/openvpn/client1.conf

          # cat /var/etc/openvpn/client1.conf
          dev ovpnc1
          dev-type tun
          dev-node /dev/tun1
          writepid /var/run/openvpn_client1.pid
          #user nobody
          #group nobody
          daemon
          client  #this was the *most* critical one word, not populated by gui, again this was KEY
          keepalive 10 60
          ping-timer-rem
          persist-tun
          persist-key
          proto udp
          cipher AES-256-CBC
          up /etc/rc.filter_configure
          down /etc/rc.filter_configure
          local 172.15.1.2
          lport 1194
          remote 96.253.96.54 1194
          comp-lzo
          tls-client
          #ifconfig 192.168.123.5 192.168.123.6   #put in by GUI, but is a mistake to include here, should be pushed from CCD
          ca /var/etc/openvpn/ca.crt  #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE
          cert /var/etc/openvpn/lynchburg.crt  #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE
          key /var/etc/openvpn/lynchburg.key  #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE
          verb 3  #for my testing
          
          

          ROUTES

          Server

          Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
          default 	96.253.96.1 	UGS 	0 	8307352 	1500 	dc1 	 
          10.1.1.0/24 	link#5 	UC 	0 	0 	1500 	xl0 	 
          10.1.1.1 	00:06:5b:c5:42:01 	UHLW 	1 	10 	16384 	lo0 	 
          10.1.1.15 	00:0d:93:4e:68:5c 	UHLW 	1 	30745 	1500 	xl0 	864
          10.1.1.27 	00:16:cb:a8:1d:7f 	UHLW 	1 	38950 	1500 	xl0 	1186
          10.1.1.40 	00:06:5b:99:34:ce 	UHLW 	1 	16279 	1500 	xl0 	1164
          10.1.1.65 	00:1e:8c:91:8a:27 	UHLW 	1 	1849710 	1500 	xl0 	624
          10.1.1.100 	00:1f:f3:5a:5f:af 	UHLW 	1 	790 	1500 	xl0 	1043
          10.1.1.101 	00:1f:5b:c6:26:e5 	UHLW 	1 	37158 	1500 	xl0 	782
          10.1.1.136 	00:02:b9:af:c9:80 	UHLW 	1 	3 	1500 	xl0 	1071
          10.1.1.150 	00:16:cb:a5:e0:ea 	UHLW 	1 	1 	1500 	xl0 	243
          10.1.1.154 	00:16:cb:a5:fe:24 	UHLW 	1 	217 	1500 	xl0 	640
          10.1.1.160 	00:1d:4f:0b:d2:e4 	UHLW 	1 	2241 	1500 	xl0 	1039
          10.1.1.188 	00:0e:08:da:31:af 	UHLW 	1 	0 	1500 	xl0 	665
          10.1.2.0/24 	link#3 	UC 	0 	0 	1500 	dc2 	 
          10.1.2.43 	00:13:d3:84:5d:e0 	UHLW 	1 	189 	1500 	dc2 	279
          10.1.5.0/24 	192.168.123.2 	UGS 	0 	5505 	1500 	ovpns1 	 
          10.1.20.0/24 	link#1 	UC 	0 	0 	1500 	dc0 	 
          96.253.96.0/24 	link#2 	UC 	0 	0 	1500 	dc1 	 
          96.253.96.1 	00:90:1a:a1:1a:18 	UHLW 	2 	29635 	1500 	dc1 	219
          96.253.96.54 	00:18:01:30:c9:61 	UHLW 	1 	7016 	16384 	lo0 	 
          127.0.0.1 	127.0.0.1 	UH 	0 	406 	16384 	lo0 	 
          192.168.123.0/24 	192.168.123.2 	UGS 	0 	85 	1500 	ovpns1 	 
          192.168.123.2 	192.168.123.1 	UH 	2 	0 	1500 	ovpns1 	 
          

          Client

          Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
          default 	172.15.1.1 	UGS 	0 	28445 	1500 	dc1 	 
          10.1.1.0/24 	192.168.123.6 	UGS 	0 	1614 	1500 	ovpnc1 	 
          10.1.5.0/24 	link#3 	UC 	0 	0 	1500 	xl0 	 
          10.1.5.1 	00:06:5b:68:89:9b 	UHLW 	1 	6 	16384 	lo0 	 
          10.1.5.5 	00:14:51:6f:8b:16 	UHLW 	1 	1 	1500 	xl0 	1065
          10.1.5.100 	00:17:f2:da:e0:b4 	UHLW 	1 	865 	1500 	xl0 	457
          10.1.5.228 	00:50:94:fb:e2:78 	UHLW 	1 	1 	1500 	xl0 	18
          10.1.5.232 	00:1f:f3:3f:0a:5e 	UHLW 	1 	1487 	1500 	xl0 	839
          10.1.6.0/24 	link#1 	UC 	0 	0 	1500 	dc0 	 
          127.0.0.1 	127.0.0.1 	UH 	0 	1 	16384 	lo0 	 
          172.15.0.0/16 	link#2 	UC 	0 	0 	1500 	dc1 	 
          172.15.1.1 	00:04:dd:2d:49:20 	UHLW 	2 	41498 	1500 	dc1 	291
          172.15.1.2 	00:14:bf:54:8a:7a 	UHLW 	1 	79 	16384 	lo0 	 
          192.168.123.0/24 	192.168.123.6 	UGS 	0 	38 	1500 	ovpnc1 	 
          192.168.123.6 	192.168.123.5 	UH 	2 	0 	1500 	ovpnc1 	 
          

          Edited to add -
          When I ping from clients on either side of the VPN, the firewall logs seem to suggest things are working

          IE: from Machine X (10.1.5.100) on Network B (10.1.5.0/24)
          ssh 10.1.1.100 (Machine A on Network A)
          Firewall Log shows:

          PASS Apr 9 22:13:28 LAN 10.1.5.100:53347 10.1.1.101:22 TCP:S

          From Machine A (10.1.1.100) on Network A (10.1.1.0/24)
          ssh 10.1.5.100 (Machine X on Network B)

          PASS  Apr 9 22:13:09 ovpns1 10.1.5.100:53343 10.1.1.101:22 TCP:S

          1 Reply Last reply Reply Quote 0
          • S
            SpaceBass last edited by

            Wanted to close the loop on this one …
            Did a fresh install on both ends and used my hand-coded confs (above) and it worked!

            presumably there was something sticking around from the 1.2.x upgrade to 2.0 ...

            These confs work but the ones produced from the GUI do not.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post