Site to site without routing all traffic



  • I've been working on site-to-site VPN to allow access to remote servers without routing all internet bound traffic through the tunnel.

    serverA    <->  pfsenseA (ovpn server) <-> internet <-> pfsenseB (ovpn client) <-> clientB

    summary:
    serverA can ping pfsenseB (but ONLY on the assigned IP to the openvpn client, and no other IPs associated with pfsenseB local networks)
    pfnsenseA, same as above
    pfsenseB can ping pfsenseA (all IPs associated with local interfaces)
    pfsenseB can ping serverA
    clientB can ping pfsensB client IP address assigned to pfsenseB by openvpn server
    clientB cannot ping pfsensA openvpn server ip address.
    clientB cannot ping any pfsenseA local networks.

    We have openVPN set up and working fine for remote clients (laptops and the like) except for this other site.
    After configuring the pfsenseB box as a client it gets an IP address and the pfsenseB box itself can ping serverA, but it doesn't push that route to its local networks. that is clientB cannot ping serverA but pfsenseB can.

    To make sure clients on both networks don't use the VPN tunnel for normal internet bound traffic we checked the "Don't Pull Routes" option on the pfsenseB client.

    We've checked firewall logs on both pfsenseB and pfsenseA and it doesn't seem to have anything blocked, the rules are now allow anything from the openVPN interface and all clients work just fine (including pfsenseB itself) but any hosts on local network attached to pfsenseB cannot access the A network.

    The routing table in pfsenseB does show a complete route from the openvpn client ip, to the openvpn server ip, to the serverA's network and vice versa. (the routes were populated using RIP)



  • Please post your server1.conf and client1.conf.

    To make sure clients on both networks don't use the VPN tunnel for normal internet bound traffic we checked the "Don't Pull Routes" option on the pfsenseB client.

    The routing for the tunnel is explicit.  PFsense will only route traffic over the tunnel that it is explicitly configured to be routed over the tunnel.  This step was unnecessary and can be reverted since you have access to both sides and know how each side is configured.

    I would also add an any/any rule to all your interfaces until basic connectivity is established.



  • When "Don't Pull Routes" is enabled, only pfsenseB on site b has access to the internet and can touch siteA. When enabled clientB can no longer touch the internet and still cannot touch siteA.

    server1.conf

    dev ovpns1
    verb 1
    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
    auth SHA512
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local <pfsensea wan="" ip="" address="">engine cryptodev
    tls-server
    server 10.1.1.0 255.255.255.240 <pfsensea vpn="" server="" network="">client-config-dir /var/etc/openvpn-csc/server1
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPN+Cert' 1"
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 12
    push "route 10.10.10.0 255.255.255.0" <this is="" lan="" on="" "a"="" side="">push "dhcp-option DOMAIN <pfsensea domain="" name="">"
    push "dhcp-option DNS 10.1.1.1"
    push "dhcp-option DNS 8.8.8.8"
    push "redirect-gateway def1"
    client-to-client
    ca /var/etc/openvpn/server1.ca 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.4096
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    persist-remote-ip
    float
    topology subnet
    route 10.10.20.0 255.255.255.0 <this is="" lan="" on="" "b"="" side="">route-metric 10</this></pfsensea></this></pfsensea></pfsensea> 
    

    client1.conf

    dev ovpnc2
    verb 4
    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-256-CBC
    auth SHA512
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local <pfsensb wan="" ip="">tls-client
    client
    lport 0
    management /var/etc/openvpn/client2.sock unix
    remote <pfsensea wan="" domain="" name="">1194
    ifconfig 10.1.1.2 10.1.1.1
    route 10.10.20.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
    comp-lzo adaptive
    resolv-retry infinite
    topology subnet
    route-nopull
    remote-cert-tls server</pfsensea></pfsensb> 
    


  • I apologize for the delay, I haven't had a chance to look thru the configs yet, but I will.  The reason the client's internet traffic is routed thru the tunnel is because the server is pushing that option to the client via the "push "redirect-gateway def1"" line.  Which tells me you have the "Redirect Gateway" box check in your server config.  If you uncheck that box, you won't need the "Don't pull routes" option on the remote end.  Remove those options on both ends.



  • As I look at your configs I see a few things.  First, when I see these options in your server config:

    push "dhcp-option DOMAIN <pfsensea domain="" name="">"
    push "dhcp-option DNS 10.1.1.1"
    push "dhcp-option DNS 8.8.8.8"
    client-to-client</pfsensea>

    It tells me that you're most likely using server mode "Remote Access (SSL/TLS)", which is the wrong server mode because those options are not available on a site-to-site tunnel config.  It looks like you're using certs, so change your server mode to "Peer to Peer (SSL/TLS)".  Otherwise, "Peer to Peer (SSL/TLS)" for PSK.

    route 10.10.20.0 255.255.255.0<this is="" lan="" on="" "b"="" side=""></this>

    On the server config, this line was added to the "Custom Options" box, which is unnecessary.  Remove your custom option and add "10.10.20.0/24" to the IPv4 Remote network(s) box and this line will be auto-generated.


    If I put your inital network map together with your current server config, we have this info:

    Server A LAN = 10.10.10.0/24
    Server B LAN = 10.10.20.0/24
    Tunnel Network = 10.1.1.1/28

    And your network map would look like this:

    serverA (10.10.10/24) <->  pfsenseA (ovpn server, 10.1.1.1) <-> internet <-> pfsenseB (ovpn client,10.1.1.2) <->  clientB (10.10.20.0/24)

    Assuming the above info is correct, the client-side is routing the wrong network over the tunnel with:

    route 10.10.20.0 255.255.255.0

    On the client-side, change the IPv4 Remote network(s) setting to 10.10.10.0/24.


    Once all the above changes are made, you should be good to go, but I would do a couple things before you begin testing:

    • Add any/any rules to both the OpenVPN tab and LAN tab on both sides until basic IP connectivity is established

    • If you're testing with windows machines, remember that ICMP echo reply is disabled by default for traffic sourced outside of the machine's local subnet, which means your pings will fail unless you create firewall exceptions, the machines are on a domain or you disable the windows firewall altogether.



  • Can we assume no news is good news?