Site to site without routing all traffic

s4stevo

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)

marvosa

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.

s4stevo

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>

marvosa

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.

marvosa

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.

marvosa

Can we assume no news is good news?