Site-to-site tunnel, remote dont have route but can ping network
-
I'll try to explain short!
Site B connect through OpenVPN site-to-site config to Site A since long time everything working well. All remote network in 192.168.x.x are setup on the client side in IPv4 Remote networks.
On site A, I just add new VLAN network (10.10.x.x) on new Ubiquiti networks managed L3 switch. Eveyrthing is managed for this and routing is working on site A. I just had to manage and add some routes on my pfsense to allow packets to return back to these new networks through the InterVLAN imposed by Ubiquiti!
For now, everything is open on my openVPN firewall rules on both pfsense.
I never added these new networks on site B OpenVPN client config, but I still can ping each VLAN GW interfaces on these networks? Note that I can't ping computer on these VLANs, only the gateway at exemple 10.10.3.1/24
Is it normal? Just need to know. I will need to add some route on Site B OpenVPN client side, but before add it, I need to know if this behavior is normal?
And by the way, what is the better good practice to add route to allow client side (site B) access to a new network on OpenVPN server site? add it to client side or from serveur side if its possible? ... client specific Overrides? In each situation, I need some advice before changing each setup on each pfsense because I have more than 10 site-to-site tunnel!
Thanks!
-
@M0L50N said in Site-to-site tunnel, remote dont have route but can ping network:
I never added these new networks on site B OpenVPN client config, but I still can ping each VLAN GW interfaces on these networks? Note that I can't ping computer on these VLANs, only the gateway at exemple 10.10.3.1/24
Is it normal? Just need to know. I will need to add some route on Site B OpenVPN client side, but before add it, I need to know if this behavior is normal?
Maybe the server pushes the route to the client?
This would be the case, if you have entered the new subnet into the "local networks" box in the server settings and if in the client settings "Don't pull routes" and "Don't add/remove routes" is unchecked.And by the way, what is the better good practice to add route to allow client side (site B) access to a new network on OpenVPN server site? add it to client side or from serveur side if its possible? ... client specific Overrides?
Just add the new subnet to "remote networks" in the client settings.
Client specific overrides is only needed for accessing subnets on the client site.
-
@viragomann said in Site-to-site tunnel, remote dont have route but can ping network:
Maybe the server pushes the route to the client?
This would be the case, if you have entered the new subnet into the "local networks" box in the server settings and if in the client settings "Don't pull routes" and "Don't add/remove routes" is unchecked.It's not the case, no new subnet in local networks box in server settings. On my site A, the only place new VLANs networks 10.10.x.x are for now its static route to allow traffic between pfsense and my VLANs
That's probably the reason they reply ... pfsense know these networks through the InterVLAN from Ubiquiti ... what do you think about that idea?
Thanks
-
@M0L50N
The static routes at A have to impact at B.So what are the routes at the B site router?
I'd expect that the new VLANs are included there for some reason.
And what are the OpenVPN settings?Also you can check out the OpenVPN log and look for an entry about adding routes.
-
@viragomann
I didn't check the logs, but if routes were pushed by server or something, I should see them in mmy routes list. Like you can see, no route in 10.10.x.x subnet ...
Strangely, 10.10.2.1 and 10.10.4.1 reply to ping, but no 10.10.3.1 .... same settings for VLANs, Ubiquiti and pfsense ...
-
@M0L50N
Strange.
If there are no routes on B I'd expect that packets destined to the new networks are sent out to the default gateway.To investigate this, I'd sniff the traffic on both interfaces, the VPN and the default upstream interface.
-
@viragomann That's what I've done. A lot of sniffing and I saw nothing related to that anywhere, but I got answer when sending ping from site B to new networks VLAN GW!!!
I disconnected the tunnel between 2 sites ... and continued to get ICMP reply!!!! HaHa!!! At this time I was really surprised until I realized with traceroute that the ping request from site B passed through the WAN ISP IP to come back immediately at next hop with an answer with 74-75ms delay ... Then I didn't have choice to assume that something on my ISP network replied back to my ping.
I dont understand why device with 10.10.2.1 on ISP network answer, but that's the only explanation. That's why I've found nothing while I was sniffing on site A equipment!!! HaHA!!!
Thanks to help me!
-
@M0L50N
Normally RFC 1918 addresses should neither be routed in the internet nor responded.
But as you pointed out, that's the only explanation for getting responses.Anyway, adding the routes for site A will override the default route, and traffic to the remote site should be routed properly over the VPN then.
-
@viragomann But if I got problem with the tunnel, some sensitive traffic can be sent to this equipment? I will contact them to understand this ... but do you have a suggestion to block traffic to go there if my tunnel is down?
-
@M0L50N
Yes, of course, if the tunnel goes (routes cleared) down traffic destined to the remote site will go out to the default gateway.You can circumvent this by adding a floating Quick block rule to WAN for outgoing traffic to RFC1918 destinations.
RFC1918 is an alias containing all private network ranges. You have to create it before.
-
@viragomann said in Site-to-site tunnel, remote dont have route but can ping network:
Yes, of course, if the tunnel goes (routes cleared) down traffic destined to the remote site will go out to the default gateway.
You can circumvent this by adding a floating Quick block rule to WAN for outgoing traffic to RFC1918 destinations.
RFC1918 is an alias containing all private network ranges. You have to create it before.Thanks!