PeertoPeer SSL/TLS wrong route creation
-
Having a problem connecting two PfSense-boxes with OVPN.
The tunnel comes up, but the routes are set wrong or the IP assigned to the client is wrong.In Detail:
ServerNW: 192.168.15.0/24
ClientNW: 192.168.0.0/24
TunnelNW: 10.0.8.0/24
After Tunnel is up the Client recieves the address 10.0.8.6 and a route to 192.168.15.0/24 pointing to 10.0.8.5 is created.
On serverside the TUN-IP is 10.0.8.1 and the route 192.168.0.0/24 ist created but pointing to 10.0.8.2 although the VPN-log shows the client connected with IP 10.0.8.6
On clientside i can ping 10.0.8.1 and on Serverside i can ping 10.0.8.6 but the local network behind the tunnel cannnot be reached because of the wrong routes. FW-Rules for OVPN-IF are created.Tried a ClientSpecificOverride where i pushed the 10.0.8.1 to the client. After that, routes and addresses were set correct. But with that config I wasn't even able to ping the Tunnel-IP on the other side.
I think there must be another way because I had the same setup running a few weeks ago without any problem and without CSO, but had to reinstall one machine and build new certs etc.Version is 2.0 RC2
Any ideas what could be wrong here?
THX
-
If you're using SSL/TLS this is the way it works.
Each connecting client is moved into its own /30 subnet with the first being .5 and .6.
If you connect another client you would see that the second would be with the ips .9 an .10.If you want a simple tunnel then you might consider not using SSL/TLS but a shared key.
-
Thanks. I think a have to learn a little bit more about ovpn. I thought the tunnel network ist just a /24 subnet where Server and Clients can communicate.
But it works now.
Had the problem that on Serverside there is a multiwan configuration and a firewallrule which directs traffic from lan to a Gatewaypool.
This rule caused the traffic with destination to remotenetwork going directly to the gatewaypool and not through the tunnel. So I created a rule with destination 192.168.0.0/24 without any gatewaysetting and it works perfect now.
But is this normal behavior? My IP-Sec-Tunnels weren't affected by this rule.
