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/28And 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?