Routing issues between networks behind openvpn routers



  • Hi all,

    I am a bit struggling with my VPN setup. It looks something like:

    LAN1: 10.0.0.0/24 ===> OVPN-GW <=== big bad internet ====> branch office router <=== LAN2: 10.0.11.0/24

    OpenVPN-Gateway is running OpenBSD 5.2 and OpenVPN 2.2.2.
    The branch office router is running pfsense 2.0.3-RELEASE (amd64)

    IP-range for the clients on the VPN is 10.0.1.0/24 (tun).

    My goal was to allow the users in LAN2 access to LAN1. OpenVPN configuration seems to be fine, as the connection is fine and pinging the OVPN-GW from the pfsense console is possible. The firewall on pfsense was temporary set to allow all traffic. Also on OpenBSD's pf  "pass in" && "pass out" were temporary activated for testing purpose, but I had no luck accessing LAN1 from LAN2.

    What also seemed a bit strange on this OpenVPN setup generally is that, pinging the server from the clients is successful, but not the other way round. Is this behavior correct? Ping from server to client fails.

    Has anybody some hints on this, or maybe can give me some clue on how to debug this issue? To me it seems a lot of a routing issue.

    Thank you!

    Best regards

    ========= routing table OVPN-GW =========

    Internet:
    Destination        Gateway            Flags  Refs      Use  Mtu  Prio Iface
    default            x.x.6.1            UGS        6  149158    -    8 em0 
    x.x.6.0/27        link#1            UC        1        0    -    4 em0 
    x.x.6.1            78:fe:3d:47:19:0f  UHLc      1        0    -    4 em0 
    x.x.6.24          127.0.0.1          UGHS      0        0 33196    8 lo0 
    10.0.0/24          link#2            UC        1        0    -    4 em1 
    10.0.0.2          08:00:27:45:c7:c1  UHLc      3  150838    -    4 em1 
    10.0.1/24          10.0.1.2          UGS        0    38419    -    8 tun0
    10.0.1.2          10.0.1.1          UH        1        0    -    4 tun0
    127/8              127.0.0.1          UGRS      0        0 33196    8 lo0 
    127.0.0.1          127.0.0.1          UH        2    31314 33196 L  4 lo0 
    224/4              127.0.0.1          URS        0        0 33196    8 lo0

    ========= routing table branch office router =========

    IPv4
    Destination Gateway Flags Refs Use Mtu Netif Expire
    default x.x.29.201 UGS 0 2060 1500 em1
    10.0.0.0/24 10.0.1.1 UGS 0 0 1500 ovpnc1
    10.0.1.0/24 10.0.1.9 UGS 0 977 1500 ovpnc1
    10.0.1.9 link#10 UH 0 0 1500 ovpnc1
    10.0.1.10 link#10 UHS 0 0 16384 lo0
    10.0.10.0/24 link#3 U 0 447 1500 em2
    10.0.10.11 link#3 UHS 0 0 16384 lo0
    10.0.11.0/24 link#1 U 0 2225 1500 em0
    10.0.11.11 link#1 UHS 0 0 16384 lo0
    x.x.29.200/29 link#2 U 0 987 1500 em1
    x.x.29.203 link#2 UHS 0 0 16384 lo0
    127.0.0.1 link#7 UH 0 13 16384 lo0

    ========= routing table computer in LAN2 =========

    IPv4-Routentabelle
    Aktive Routen:
        Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
              0.0.0.0          0.0.0.0      10.0.11.11      10.0.11.101    266
            10.0.11.0    255.255.255.0  Auf Verbindung      10.0.11.101    266
          10.0.11.101  255.255.255.255  Auf Verbindung      10.0.11.101    266
          10.0.11.255  255.255.255.255  Auf Verbindung      10.0.11.101    266
            127.0.0.0        255.0.0.0  Auf Verbindung        127.0.0.1    306
            127.0.0.1  255.255.255.255  Auf Verbindung        127.0.0.1    306
      127.255.255.255  255.255.255.255  Auf Verbindung        127.0.0.1    306
            224.0.0.0        240.0.0.0  Auf Verbindung        127.0.0.1    306
            224.0.0.0        240.0.0.0  Auf Verbindung      10.0.11.101    266
      255.255.255.255  255.255.255.255  Auf Verbindung        127.0.0.1    306
      255.255.255.255  255.255.255.255  Auf Verbindung      10.0.11.101    266

    ========= routing table computer in LAN1 =========

    Kernel IP routing table
    Destination    Gateway        Genmask        Flags  MSS Window  irtt Iface
    0.0.0.0        10.0.0.1        0.0.0.0        UG        0 0          0 eth0
    10.0.0.0        0.0.0.0        255.255.255.0  U        0 0          0 eth0
    127.0.0.0      0.0.0.0        255.0.0.0      U        0 0          0 lo
    169.254.0.0    0.0.0.0        255.255.0.0    U        0 0          0 eth0



  • Which side is server and which side is the client?

    I do not see a route to 10.0.11.0/24 on the OVPN-GW side… that's likely your issue

    Post the config files from both sides (e.g. server1.conf and client1.conf)



  • Hi,

    sorry I forgot some information. OVPN-GW is the server and pfsense the client.

    Adding the according route on the server fails with:

    route add -net 10.0.11.0/24 10.0.1.10

    route: writing to routing socket: Network is unreachable
    add net 10.0.11.0/24: gateway 10.0.1.10: Network is unreachable

    This will probably be caused by the server not being able reach the clients, as also "ping 10.0.1.10" times out. 10.0.1.10 is the client IP shown by pfsense. So I can assume this behavior is not supposed to be okay? Any ideas on this?

    Thank you!

    Best regards

    ====== server.conf ======

    proto udp
    port 444
    dev tun0
    ca /etc/openvpn/ca.crt
    cert /etc/openvpn/private/cert.cc.crt
    key /etc/openvpn/private/key.key
    dh /etc/openvpn/dh2048.pem

    server 10.0.1.0 255.255.255.0

    keepalive 10 120
    comp-lzo
    user openvpn
    group openvpn
    daemon openvpn
    persist-key
    persist-tun

    tls-auth /etc/openvpn/private/ta.key 0
    cipher AES-256-CBC

    push "route 10.0.0.0 255.255.255.0"
    push "dhcp-option DNS 10.0.0.2"
    client-to-client

    status /var/log/openvpn-status.log

    ====== client config ======

    client
    dev tun
    proto udp
    remote server 444
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert client.crt
    key client.key
    tls-auth ta.key 1
    cipher AES-256-CBC
    comp-lzo
    verb 3



  • Information I see (let me know if any of this is not correct:
    Tunnel Network - 10.0.1.0/24
    LAN1 - 10.0.0.0/24
    LAN2 - 10.0.11.0/24

    From the above info, it looks like the following is missing:

    SERVER
    –--------
    ifconfig 10.0.1.1 10.0.1.2
    route 10.0.11.0 255.255.255.0

    CLIENT

    ifconfig 10.0.1.2 10.0.1.1
    route 10.0.0.0 255.255.255.0

    Also that client config... are you sure you pulled that from a PFsense box?  Because if you enter the relevant info into the client section of OpenVPN... it should look similar to this:

    dev ovpnc2
    dev-type tun
    dev-node /dev/tun2
    writepid /var/run/openvpn_client2.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local WAN_IP_OF_LAN2
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client2.sock unix
    remote WAN_IP_OF_LAN1 1194
    ifconfig 10.0.1.2 10.0.1.1
    route 10.0.0.0 255.255.255.0
    ca /var/etc/openvpn/client2.ca
    cert /var/etc/openvpn/client2.cert
    key /var/etc/openvpn/client2.key
    tls-auth /var/etc/openvpn/client2.tls-auth 1



  • Hey,

    sorry for the delay. Didn't have any access to the system until now ….

    I tried adding the routes as you suggested, but had no luck :(

    And sorry for the wrong config-file; seem to have taken the wrong one ...

    dev ovpnc1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local x.x.29.203
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote SERVER_DNS 444
    ca /var/etc/openvpn/client1.ca
    cert /var/etc/openvpn/client1.cert
    key /var/etc/openvpn/client1.key
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    comp-lzo
    tls-auth /etc/tls.auth 1



  • You are still missing info. After you've entered everything, your config should look identical to mine with the excepttion of the WAN IP's.



  • Marvosa - This is related but unrelated…

    Ubuntu doesn't route to LANs the way it should automatically the way windows does when its a client to a pfsense TUN openvpn.

    This little line you mentioned earlier totally fixed a looooonnnnnnggggggg standing issue of ubuntu to make it route to LANs.

    In the client file on ubuntu, near bottom placed:
    route 10.0.0.0 255.255.255.0  (substituted my LAN Subnet)

    I haven't ever seen a good fix for this anywhere, but this is so simple.  Why didn't I do earlier (pfsense needs a facepalm icon) :-[

    So, you are a genius.  Thank you much for the accidental unrelated help  :)

    keywords added for web searches:

    ubuntu linux mint pfsense openvpn can't access LAN TUN client



  • Just to clarify my first post, those missing lines need to be added to your config… not added via command line after connection.



  • Yeah sure, but as I told previously I still can't get any connection …

    new pfsense config

    dev ovpnc1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local x.x.29.203
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote HOST 444
    ca /var/etc/openvpn/client1.ca
    cert /var/etc/openvpn/client1.cert
    key /var/etc/openvpn/client1.key
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    comp-lzo
    tls-auth /etc/tls.auth 1
    ifconfig 10.0.1.2 10.0.1.1
    route 10.0.0.0 255.255.255.0

    new server config:

    proto udp
    port 444
    dev tun0

    ifconfig 10.0.1.1 10.0.1.2
    route 10.0.11.0 255.255.255.0

    ca /etc/openvpn/ca.crt
    cert /etc/openvpn/private/picard.goetzinger.cc.crt
    key /etc/openvpn/private/picard.goetzinger.cc.key
    dh /etc/openvpn/dh2048.pem

    server 10.0.1.0 255.255.255.0

    keepalive 10 120
    comp-lzo

    user openvpn
    group openvpn
    daemon openvpn

    persist-key
    persist-tun

    tls-auth /etc/openvpn/private/ta.key 0
    cipher AES-256-CBC

    push "route 10.0.0.0 255.255.255.0"
    push "dhcp-option DNS 10.0.0.2"
    client-to-client

    status /var/log/openvpn-status.log



  • Client-side looks right, although it looks like you added the lines manually to the advanced section instead of letting the system generate it ("should" work either way).

    Is the tunnel established?  If so, probably looking at firewall rules.

    Post the firewall rule from the OpenVPN tab on PFsense.

    Posting routing tables from both firewalls might help as well.



  • Sure, tunnel status has been fine, since initial setup.

    Firewall rules at OpenBSD are

    pass in
    pass out

    Firewall rules at the pfsense are

    Proto TCP
    Source *
    Port *
    Destination *
    Port *
    Gateway *
    Queue None

    Routing table at pfsense:

    IPv4
    Destination Gateway Flags Refs Use Mtu Netif Expire
    default   85.126.x.x UGS 0 4386 1500 em1
    10.0.0.0/24 10.0.1.1 UGS 0 24 1500 ovpnc1
    10.0.1.0/24 10.0.1.5 UGS 0 1699 1500 ovpnc1
    10.0.1.5 link#10 UH 0 0 1500 ovpnc1
    10.0.1.6 link#10 UHS 0 0 16384 lo0
    10.0.10.0/24 link#3 U 0 0 1500 em2
    10.0.10.11 link#3 UHS 0 0 16384 lo0
    10.0.11.0/24 link#1 U 0 4693 1500 em0
    10.0.11.11 link#1 UHS 0 0 16384 lo0
    85.126.x.x/29 link#2 U 0 1709 1500 em1
    85.126.x.x link#2 UHS 0 0 16384 lo0
    127.0.0.1 link#7 UH 0 26 16384 lo0

    Routing table at OpenBSD:

    Destination        Gateway            Flags  Refs      Use  Mtu  Prio Iface
    default            static.1.6.9.5.cli UGS      12  889109    -    8 em0 
    static.0.6.9.5.cli link#1            UC        1        0    -    4 em0 
    static.1.6.9.5.cli 78:fe:3d:47:19:0f  UHLc      2        0    -    4 em0 
    picard            localhost          UGHS      0        0 33196    8 lo0 
    10.0.0/24          link#2            UC        1        0    -    4 em1 
    planck            08:00:27:45:c7:c1  UHLc      2  606332    -    4 em1 
    10.0.1/24          10.0.1.2          UGS        0  285890    -    8 tun0
    10.0.1.2          10.0.1.1          UH        2        0    -    4 tun0
    10.0.11/24        10.0.1.2          UGS        0        0    -    8 tun0
    85-126-x-x.work static.1.6.9.5.cli UGHD      2  888959    - L  56 em0 
    loopback          localhost          UGRS      0        0 33196    8 lo0 
    localhost          localhost          UH        7  145056 33196 L  4 lo0 
    BASE-ADDRESS.MCAST localhost          URS        0        0 33196    8 lo0

    Thank you!



  • Something's fishy… It looks like PFsense is trying to route 10.0.0.0/24 through 10.0.1.1 (which should be other end of the tunnel), but the system thinks the other end of the tunnel is 10.0.1.5.  Do you have any manual routes added?

    I would start by removing any manually added routes, then:

    Client side:

    • remove the ifconfig and route lines from the advanced section and enter the appropriate information into the Tunnel Settings section of the GUI and let PFsense generate those lines

    • Reboot PFsense

    Server side:

    • even know the server-side looks ok, I would place the ifconfig line underneath the server line

    • place the route statement down by the push lines

    • I'm also wondering on the server side if you need to change "dev tun0" to just "dev tun" (I believe you would only use that if you have multiple connections and want to bind each connection to a separate interface)

    After that I would turn on logging of your firewall rules on the openvpn interface on both sides and verify that you're not getting blocks.



  • Okay, logging is turned on and everything is passed.

    logs:

    pass Oct 6 14:47:32 LAN 10.0.11.107 10.0.0.2 ICMP

    the routes look way better now on the pfsense:

    IPv4
    Destination Gateway Flags Refs Use Mtu Netif Expire
    default 85.126.29.201 UGS 0 38 1500 em1
    10.0.0.0/24 10.0.1.5 UGS 0 36 1500 ovpnc1
    10.0.1.0/24 10.0.1.5 UGS 0 0 1500 ovpnc1
    10.0.1.5 link#10 UH 0 0 1500 ovpnc1
    10.0.1.6 link#10 UHS 0 0 16384 lo0
    10.0.10.0/24 link#3 U 0 0 1500 em2
    10.0.10.11 link#3 UHS 0 0 16384 lo0
    10.0.11.0/24 link#1 U 0 3994 1500 em0
    10.0.11.11 link#1 UHS 0 0 16384 lo0
    85.126.29.200/29 link#2 U 0 174 1500 em1
    85.126.29.203 link#2 UHS 0 0 16384 lo0
    127.0.0.1 link#7 UH 0 33 16384 lo0

    but I still have no connection to 10.0.0.0/24; though pinging 10.0.1.6 works


Log in to reply