Site to site OpenVPN issues



  • Hello folks.

    I have created a site-to-site VPN as per the instructions at https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_(Shared_Key,_2.0)

    The VPN is shown as up and running from both sides, but no one can ping a host from the client LAN to the VPN server's LAN except the pfsense box which acts as the OpenVPN client.

    The client's LAN is 192.168.1.0/24 and the server's 172.16.0.0/22. I have chosen the 172.16.10.0/23 subnet as the tunnel (waste, but will fix to a more reasonable range once I fix the issues).

    Here's the config:

    Server:

    <openvpn><openvpn-server><vpnid>1</vpnid>
    <mode>p2p_shared_key</mode>
    <protocol>UDP</protocol>
    <dev_mode>tun</dev_mode>
    <ipaddr>–RESERVED--</ipaddr>
    <interface>wan_vip9</interface>
    <local_port>1200</local_port>

    <custom_options>verb 5;</custom_options>
    <shared_key>–RESERVED--</shared_key>
    <crypto>AES-256-CBC</crypto>
    <engine>none</engine>
    <tunnel_network>172.16.10.0/23</tunnel_network>
    <tunnel_networkv6><remote_network>192.168.1.0/24</remote_network>
    <remote_networkv6><gwredir><local_network>172.16.0.0/22</local_network>
    <local_networkv6><maxclients>300</maxclients>
    <compression>yes</compression>
    <passtos><client2client><dynamic_ip><pool_enable>yes</pool_enable>
    <topology_subnet><serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface>
    <serverbridge_dhcp_start><serverbridge_dhcp_end><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></topology_subnet></dynamic_ip></client2client></passtos></local_networkv6></gwredir></remote_networkv6></tunnel_networkv6></openvpn-server></openvpn>

    Client:

    <openvpn-client><vpnid>2</vpnid>
    <protocol>UDP</protocol>
    <dev_mode>tun</dev_mode>
    <ipaddr><interface>wan</interface>
    <local_port><server_addr>--RESERVED--</server_addr>
    <server_port>1200</server_port>
    <resolve_retry><proxy_addr><proxy_port><proxy_authtype>none</proxy_authtype>
    <proxy_user><proxy_passwd><mode>p2p_shared_key</mode>
    <custom_options>verb 5;</custom_options>
    <shared_key>–RESERVED--</shared_key>
    <crypto>AES-256-CBC</crypto>
    <engine>none</engine>
    <tunnel_network>172.16.10.0/23</tunnel_network>
    <tunnel_networkv6><remote_network>172.16.0.0/22</remote_network>
    <remote_networkv6><use_shaper><compression>yes</compression>
    <passtos></passtos></use_shaper></remote_networkv6></tunnel_networkv6></proxy_passwd></proxy_user></proxy_port></proxy_addr></resolve_retry></local_port></ipaddr></openvpn-client>

    Now, as I already mentioned, my pfsense client box has no problems actually accessing the hosts:

    [2.1-RELEASE][root@korriban]/root(28): ping 172.16.0.10
    PING 172.16.0.10 (172.16.0.10): 56 data bytes
    64 bytes from 172.16.0.10: icmp_seq=0 ttl=63 time=32.569 ms
    64 bytes from 172.16.0.10: icmp_seq=1 ttl=63 time=31.891 ms
    64 bytes from 172.16.0.10: icmp_seq=2 ttl=63 time=31.996 ms
    64 bytes from 172.16.0.10: icmp_seq=3 ttl=63 time=32.771 ms
    64 bytes from 172.16.0.10: icmp_seq=4 ttl=63 time=32.642 ms

    [2.1-RELEASE][root@korriban]/root(29): traceroute 172.16.0.10
    traceroute to 172.16.0.10 (172.16.0.10), 64 hops max, 52 byte packets
    1  172.16.10.1 (172.16.10.1)  31.954 ms  31.211 ms  31.755 ms
    2  172.16.0.10 (172.16.0.10)  32.006 ms  32.415 ms  32.218 ms

    But hosts inside our pfsense client's LAN:

    C:\windows\system32>tracert 172.16.0.10

    Tracing route to 172.16.0.10 over a maximum of 30 hops

    1    3 ms    7 ms    3 ms  korriban [192.168.1.1]
      2    *        *        *    Request timed out.
      3    *        *        *    Request timed out.
      4  ^C

    And right when you thought that it was a simple routing problem:

    C:\windows\system32>ping 172.16.10.1

    Pinging 172.16.10.1 with 32 bytes of data:
    Reply from 172.16.10.1: bytes=32 time=36ms TTL=63
    Reply from 172.16.10.1: bytes=32 time=38ms TTL=63
    Reply from 172.16.10.1: bytes=32 time=35ms TTL=63

    Ping statistics for 172.16.10.1:
        Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 35ms, Maximum = 38ms, Average = 36ms
    Control-C
    ^C

    C:\windows\system32>tracert 172.16.10.1

    Tracing route to 172.16.10.1 over a maximum of 30 hops

    1    7 ms    3 ms    3 ms  korriban [192.168.1.1]
      2    37 ms    35 ms    35 ms  172.16.10.1

    Trace complete.

    (For those lost 172.16.10.1 is the server's tunnel IP)

    Any ideas?

    Thanks in advance.



  • I don't know about anyone else, but it's much easier to read the server1.conf and client1.conf.  Can you post those?  Also, make sure there's an any/any firewall rule on the openvpn tab on both sides.



  • Hi,

    I would be nice if we can see the routing tables at both client and server end.
    do a "netstat -nr" at both sides and post it here or go to Diagnostics -> Routes.



  • Hi again guys and thank you for your input. The "Allow All" rule in the OpenVPN tab exists in both parties.

    IPv4 * * * * * * none   Allow all through the VPN tunnel

    Here's the server1.conf and the routing table on the server:

    [2.1-RELEASE][root@coruscant]/var/etc/openvpn(5): more server1.conf
    dev ovpns1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.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 –RESERVED--
    ifconfig 172.16.10.1 172.16.10.2
    lport 1200
    management /var/etc/openvpn/server1.sock unix
    max-clients 300
    push "route 172.16.0.0 255.255.252.0"
    route 192.168.1.0 255.255.255.0
    secret /var/etc/openvpn/server1.secret
    comp-lzo
    verb 5

    [2.1-RELEASE][root@coruscant]/var/etc/openvpn(6): netstat -nr
    Routing tables

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            –RESERVED--          UGS        0    20766  lagg0
    8.8.8.8            --RESERVED--          UGHS        0      105  lagg0
    --RESERVED--/29      link#15            U          0    59747  lagg0
    --RESERVED--        link#18            UH          0        0 wan_vi
    --RESERVED--          link#15            UHS        0        0    lo0
    127.0.0.1          link#13            UH          0      53    lo0
    172.16.0.0/22      link#16            U          0    2354  lagg1
    172.16.0.1        link#19            UH          0        0 lan_vi
    172.16.0.2        link#16            UHS        0        0    lo0
    172.16.10.1        link#20            UHS        0        0    lo0
    172.16.10.2        link#20            UH          0      34 ovpns1
    172.16.20.0/24    172.16.20.2        UGS        0    10489 ovpns2
    172.16.20.1        link#21            UHS        0        0    lo0
    172.16.20.2        link#21            UH          0        0 ovpns2
    192.168.1.0/24    172.16.10.2        UGS        0      12 ovpns1
    192.168.250.0/30  link#17            U          0  254442  lagg2
    192.168.250.1      link#17            UHS        0        0    lo0
    --MY-DNS-SERVER--      --RESERVED--          UGHS        0      112  lagg0

    Internet6:
    Destination                      Gateway                      Flags      Netif Expire
    .....

    Here's the client1.conf and the routing table on the client:

    [2.1-RELEASE][root@korriban]/var/etc/openvpn(3): more client2.conf
    dev ovpnc2
    dev-type tun
    tun-ipv6
    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-256-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.0.2
    lport 0
    management /var/etc/openvpn/client2.sock unix
    remote –RESERVED-- 1200
    ifconfig 172.16.10.2 172.16.10.1
    route 172.16.0.0 255.255.252.0
    secret /var/etc/openvpn/client2.secret
    comp-lzo
    verb 5

    [2.1-RELEASE][root@korriban]/var/etc/openvpn(4): netstat -nr
    Routing tables

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            192.168.0.1        UGS        0  1557157    xl1
    –RESERVED--          192.168.0.1        UGHS        0    17600    xl1
    127.0.0.1          link#7            UH          0  978191    lo0
    172.16.0.0/22      172.16.10.1        UGS        0      667 ovpnc2
    172.16.10.1        link#10            UH          0      62 ovpnc2
    172.16.10.2        link#10            UHS        0        5    lo0
    192.168.0.0/24    link#3            U          0  151514    xl1
    192.168.0.2        link#3            UHS        0        0    lo0
    192.168.1.0/24    link#1            U          0 20166068    re0
    192.168.1.1        link#1            UHS        0        0    lo0
    192.168.200.0/24  192.168.200.2      UGS        0    3131 ovpns1
    192.168.200.1      link#9            UHS        0        0    lo0
    192.168.200.2      link#9            UH          0        0 ovpns1

    Internet6:
    Destination                      Gateway                      Flags      Netif Expire
    .....



  • Appreciate your folks assistance. I've managed to track down the issue. Weirdly enough it was some leftover IPSec configuration that conflicted with the VPN tunnel. All I had to do was remove it from the client and immediately it worked.

    Thanks!


Log in to reply