Routing problem with openvpn
-
Hi, a pfsense with a single Intel NIC and VLANs on it, has dual WAN (one as backup and OpenVPN server services only, the other for Internetaccess and outgoing VPN), OpenVPN Server for roadwarrior and 2 site to site connections to other PFsense on it, updated a view days ago. Every thing works fine in this configuration. Now we have to make another OpenVPN connection to a non PFsense firewall as a client. Tunnel can be engaged, but sending a ping is impossible.
In the following text TN* stands for the transfer netwark XXX.YYY.ZZZ.0/24 thus TN*.1 is an IP address in the transfer network.
Analyzing the routing table shows TN*.1 as a gateway for the remote network. In the routing table 2 entries with gateway "link#xy" for TN*.1 and TN*.2 can be found too. I guess "link#xy" means that TN*.1 and TN*.2 are some kind of bridged. This is analog to what I can see on a remote PFsense acting as a client.
Ping to the remote site is possible, if a route on the pinging maschine is added to the remote net with TN*.2 as a gateway. (In PFsenses table TN*.1 is used)Some site on the internet suggests to take out the remote net from VPN client configuration and add a route with TN*.2 via SSH, config.rc etc. I don´t like such solutions, because you can´t find them in config-firewall....xml
I think the "system-routing" menue won´t help in this situation.What has gone wrong. Why points the routing table to the transfer ip on the other side (TN*.1) and not to his own ip of the transfer net (TN*.2)?
Why does this work between pfsense only and not generally with OpenVPN?
Is there/will there be a fix for this problem?Hope I gave you enough information without boring you with a long text.
-
@pf-makes-sense said in Routing problem with openvpn:
Tunnel can be engaged, but sending a ping is impossible.
To where?
@pf-makes-sense said in Routing problem with openvpn:
In the following text TN* stands for the transfer netwark XXX.YYY.ZZZ.0/24
If it's a transfer network it should be an RFC 1918. So why are you hiding the IPs?
@pf-makes-sense said in Routing problem with openvpn:
Analyzing the routing table shows TN*.1 as a gateway for the remote network. In the routing table 2 entries with gateway "link#xy" for TN*.1 and TN*.2 can be found too. I guess "link#xy" means that TN*.1 and TN*.2 are some kind of bridged. This is analog to what I can see on a remote PFsense acting as a client.
Ping to the remote site is possible, if a route on the pinging maschine is added to the remote net with TN*.2 as a gateway. (In PFsenses table TN*.1 is used)Pretty hard to understand with your encryption.
Since it you're trying to establish a site-to-site connection, use a /30 tunnel network instead /24. Ensure to have the same at both sites.
-
Updated and simplified explanation:
@viragomann Thanks for your reply. Any RFC 1918 could be used for TN*. Let´s say it is 192.168.100.0/24. And it is distict from any other used net. O.k. You recommended a smaller net, but the functioning VPNs are /24 too. There should be no problem with the tunnel itsself, as with additional routing information on a clients sides computer, packets are passed through, and to answer another question: From a computer on site of the PFsense to the remote site and back.
Analyzing the routing table shows 192.168.100.1 (OpenVPN server side) as a gateway for the remote network. In the routing table 2 entries with gateway "link#12" for 192.168.100.1 and 192.168.100.2 (OpenVPN client side) can be found too. I guess "link#12" means that 192.168.100.1 and 192.168.100.2 are some kind of bridged. This is analog to what I can see on a remote PFsense acting as a client.
Ping to the remote site is possible, if a route on the pinging maschine is added to the remote net with 192.168.100.2 as a gateway. (In the routing table of the PFsense 192.168.100.1 is used as the gateway)Some site on the internet suggests to take out the remote net from VPN client configuration and add a route with 192.168.100.2 via SSH, config.rc etc. I don´t like such solutions, because you can´t find them in config-firewall....xml
I think the "system-routing" menue won´t help in this situation.What has gone wrong. Why points the routing table to the transfer ip on the other side (192.168.100.1) and not to his own ip of the transfer net (192.168.100.2)?
Why does this work between pfsense only and not generally with OpenVPN?
Is there/will there be a fix for this problem?Another try to desribe: A packet for a remote site computer is sent to the PFsense. The PFsense has a routing table rule to send it to 192.168.100.1. This IP is assigned to the remote site and the packet is not routed. I didn´t make this entry -it is automatically created- But it would need to be 192.168.100.2 which is an ip of PFsenses side of the tunnel.
I´m I allowed to post a link outside netgate.com? Would make the problem much clearer.