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)
Site A:
(Server.Advanced)
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> -
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 em1Site C is not a openvpn client site, it connects to Site B through a lan.
Site A :
Server1.conf:
dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 23.255.13.38
tls-server
server 192.168.100.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 10
push "route 192.168.0.0 255.255.255.0"
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.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
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"/var/etc/openvpn-csc/client1
iroute 192.168.1.0 255.255.255.0
iroute 10.0.0.0 255.0.0.0Site B:
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 118.120.180.38
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote 23.255.13.38 1194
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
comp-lzo</routers></openvpn> -
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
https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1
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]
Interface: OPT1
Protocol: any
Source: 192.168.0.0/24
Destination: any
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.
-
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.