Routing problem on site-to-site connection
I have two sites connected with OpeVPN below, Site A and Site B can successfully access each other internal network. Site B directly connects to Site C, and can access Site C also. Site A need to access Site C, but cannot. It seems the IP cannot be translated successfully, please see the ping results. Do you have any ideas what's wrong? Thanks.
Site A (192.168.0.0/24) –--- <openvpn site="" to="">------ Site B (192.168.1.0/24) ----<192.168.51.2>--<192.168.51.1>-- Site C ( 10.0.0.0/8)
route 10.0.0.0 255.0.0.0;
route 192.168.0.0 255.255.248.0;
push "route 192.168.0.0 255.255.255.0";
(Client Specific Overrides.Advanced)
iroute 192.168.1.0 255.255.255.0;
iroute 10.0.0.0 255.0.0.0;
Ping results captured on Site B port connected to Site C:
From Site A:
3 0.617589 192.168.0.129 10.1.8.5 ICMP 74 Echo (ping) request id=0x0001, seq=1057/8452, ttl=126 (no response found!)
From Site B:
1 0.000000 192.168.51.2 10.1.8.5 ICMP 74 Echo (ping) request id=0xe9d2, seq=24864/8289, ttl=128 (reply in 2)
2 0.058736 10.1.8.5 192.168.51.2 ICMP 74 Echo (ping) reply id=0xe9d2, seq=24864/8289, ttl=116 (request in 1)</openvpn>
marvosa last edited by
Please clarify your setup. Your network map suggests your sites are daisy chained and Site B is the router between A and C. Or is Site A the hub and has two separate tunnels… one to A and one to C?
Post your server and clients config files from each site.
You can actually do this without iroutes btw, but having not seen your configs yet there most likely are two different scenarios at play:
If your sites are daisy chained like your network map suggests (A<->B<->C) and you're using iroutes then your server config should be on Site B (not A) and you will need return routes on A for C and on C for A.
If Site A is your HUB with two separate tunnels to B and C, then most likely you have the iroute to 10.0.0.0/8 located on the wrong tunnel.
Site A [WAN] –-<openvpn site="" to="">--- [WAN] Site B [OPT1:192.168.51.2] –-[GW192.168.51.1]–-<routers>--- Site C
[LAN] [LAN] [LAN]
| | |
| | |
(192.168.0.0/24) (192.168.1.0/24) (10.0.0.0/8)
Site A is openvpn server, connected by other client sites.
Site B is client site, and it has a static IP to connect to Site C at OPT1.
Site B: Static Route
Destination Gateway Flags Refs Use Mtu Netif
10.0.0.0/8 192.168.51.1 UGS 0 682310 1500 em1
Site C is not a openvpn client site, it connects to Site B through a lan.
Site A :
keepalive 10 60
server 192.168.100.0 255.255.255.0
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
management /var/etc/openvpn/server1.sock unix
push "route 192.168.0.0 255.255.255.0"
tls-auth /var/etc/openvpn/server1.tls-auth 0
route 10.0.0.0 255.0.0.0
route 192.168.0.0 255.255.248.0
push "route 192.168.0.0 255.255.248.0"
iroute 192.168.1.0 255.255.255.0
iroute 10.0.0.0 255.0.0.0
keepalive 10 60
management /var/etc/openvpn/client1.sock unix
remote 220.127.116.11 1194
tls-auth /var/etc/openvpn/client1.tls-auth 1
route 192.168.0.0 255.255.248.0 push "route 192.168.0.0 255.255.248.0"
That looks a bit odd, teling each end that 192.168.0.0/21 is reachable at the other end of the OpenVPN link. But actually pfSense routing is smart enough to to also know about and deliver directly to the local LAN at siteA and siteB, not ping-pong traffic between the 2.
I suspect that the router at site C does not have a route back to site A LAN 192.168.0.0/24, or site C router has a firewall that is blocking that, or site B OPT1 has firewall rule/s that do not allow that…
Thanks for all, I found the solution from below
I added a rule to translate IP (192.168.0.0/24) to 192.168.51.2, it's working well now.
[NAT OUTBOUND Rule]
Translation: interface address
That shows that there is a device somewhere that does not have a route back to 192.168.0.0/24 or is blocking that traffic. Hiding it behind 192.168.51.2 is one way to work around that.
marvosa last edited by
It's already been said, but yes, the edge device @ site C needs a route back to 192.168.0.0/21 thru 192.168.51.2.
A few things:
Your iroutes are redundant as you are already routing (and pushing) the appropriate routes thru the tunnel.
Remove "route 192.168.0.0 255.255.248.0" from Site A's config. This directive is for the remote subnet, not local
Your NAT works, but now removes your ability to monitor, isolate and firewall connections coming from Site A on Site C. This may or may not be an issue depending on your priorities and security concerns
The edge device is not my own equipment at Site C, so I can't change anything on it.
In my 1st post, you can see the source IP of ICMP has been traslated to 192.168.51.2 from Site B 192.168.1.0/24 on OPT1, but through the vpn it still kept the same to pass to Site C, therefore it can't return back from Site C. Is it a bug or nromal ?
It is normal - whatever address you NAT the site A subnet to, that needs to be an address that site C knows how to route back to. So you probably might want it to be some address in site B, which site C already knows how to reach.