openvpn (site-to-site) routing issue
-
@jazzl0ver
Could be missing return routes in the remote end.You have "told" your local pfSense that 172.29.0.0/16 is behind/via 10.8.1.2.
But you also have to tell your remote pfSense, how to route packets back to the local pfSense.
That said:
In your 1'st example :# ping 172.29.2.176 PING 172.29.2.176 (172.29.2.176): 56 data bytes 36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.8.1.2) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 0a31 0 0000 40 01 0000 127.0.0.1 172.29.2.176The packages are "sourced from" 127.0.0.1 , and that would never work for a remote ping. But i think that source ip is rewritten to the "Outging IF":
Redirect Host(New addr: 10.8.1.2)But if that rewrite happens , then the 1'st ping , and the 2'nd should give same result. One is rewriting source for you, the other you specify i your self.
The reason it works if you specify the 10.8.1.2 , is :
The 10.8.1.x/24 network is already known at both ends , due to the OpenVPN tunnel being up./Bingo
-
@marvosa thank you for trying to help!
Here is the network layout:
Relevant part of the openvpn server's config:# cat /etc/openvpn/server/server.conf dev tun proto udp lport 1194 topology subnet server 10.8.1.0 255.255.255.0 push "route 172.22.0.0 255.255.248.0" push "route 172.29.0.0 255.255.0.0" push "dhcp-option DNS 172.29.0.2" push "block-outside-dns" push "redirect-gateway def1"Relevant part of the openvpn client config (pfsense):
# cat /var/etc/openvpn/client1.conf dev ovpnc1 dev-type tun dev-node /dev/tun1 local 172.26.1.1 client lport 0 remote vpn.remotehost.com 1194 udp4 resolv-retry infinite route-nopullI had to use CARP VIP (172.26.1.1) as a local endpoint to be able to automatically switch between ISP channels if (when) one of them goes down and to handle pfsense failover.
Let me know if you see anything.
-
@jazzl0ver
You're running an access server on the remote site. So you have to set the route on the server for the specific client using iroute as descriped here: Lans behind OpenVPNAlso not clear, why you're pushing some routes on the server and also pushing "redirect-gateway". If using the latter there is no need of pushing additional routes at all.
-
@viragomann thanks for your reply!
Yeah, there's no need to push the routes when redirect-gateway in use. I'll correct that, thanks
I'm not sure why you think the mentioned link is my case.
In my understanding pfsense should NAT outgoing ping packets into the ovpnc1's IP address (10.8.1.2) before sending them to the remote side. And it does seem to do that.
But then it does not send NATed packets into ovpnc1 interface. I ran a sniffer on ovpnc1 interface and no packets were captured while pfsense was pinging 172.29.2.176.
However, tcpdump started on pfsense's lo0 interface captured this:
# tcpdump -nn -i lo0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes 17:17:16.620353 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64 17:17:16.620430 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64 17:17:16.620452 IP 127.0.0.1 > 127.0.0.1: ICMP redirect 172.29.2.176 to host 10.8.1.2, length 36 17:17:16.620470 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64 17:17:16.620486 IP 127.0.0.1 > 127.0.0.1: ICMP redirect 172.29.2.176 to host 10.8.1.2, length 36 17:17:16.620525 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64 ... -
@bingo600 I'm sorry I didn't get what you were trying to tell me :(
-
@jazzl0ver said in openvpn (site-to-site) routing issue:
In my understanding pfsense should NAT outgoing ping packets into the ovpnc1's IP address (10.8.1.2) before sending them to the remote side.
Yeah, in this case, the proper routes to the remote site should be sufficient.
So the routes are set correctly on the client? -
@viragomann said in openvpn (site-to-site) routing issue:
So the routes are set correctly on the client?
Yep, just double checked it:
# netstat -rnW | grep 172.29 172.29.0.0/16 10.8.1.2 UGS 3760 16384 lo0Wondering why it the interface is lo0 here, but this is how pfsense set it after configuring thru web gui.
-
@viragomann well, that's interesting. I've disabled the static route in the gui and re-created it manually from cli:
# route add -net 172.29.0.0/16 10.8.1.1 add net 172.29.0.0: gateway 10.8.1.1And the issue has gone!
# ping -c 1 172.29.2.176 PING 172.29.2.176 (172.29.2.176): 56 data bytes 64 bytes from 172.29.2.176: icmp_seq=0 ttl=254 time=116.745 ms --- 172.29.2.176 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 116.745/116.745/116.745/0.000 msDo you think it's a bug?
-
@jazzl0ver
Also weird that the route shows the client IP as gateway. Should be the servers which is 10.8.1.1 as you stated. -
@jazzl0ver said in openvpn (site-to-site) routing issue:
Do you think it's a bug?
I think, you should not use static routes for remote networks across OpenVPN at all as suggested in the docs.
The proper way is to add the remote networks into the OpenVPN settings at "Remote network(s)" instead.
However, when the server is pushing the routes, there should be nothing necessary, just leave "Don't pull routes" unchecked. -
@viragomann I indeed missed that part of the docs. Thank you VERY much!!
