OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: ejprice on February 08, 2017, 03:27:20 pm
-
Hi folks,
I've been trying to set up a site to site tunnel with OpenVPN on both 16.7 and 17.1 to no avail. I have the actual tunnel connecting just fine. I have an additional OpenVPN server service running on the same OPNSense system for remote clients and that is working also. The site to site tunnel is pingable from the OPNSense firewalls. The firewalls themselves can ping remote hosts on the respective networks.
Here is the setup -
Home (client) network: 192.168.64.0/24
Work (server) networks: 192.168.29.0/24;172.16.29.0/24
OpenVPN network: 10.0.100.0/24
It seems like a routing problem however when I check the routes on both OPNSense boxes they look right
Home (client)
ejprice@hades:~ % netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 148.74.168.1 UGS bge1
10.0.10.0/24 10.0.100.1 UGS ovpnc1
10.0.100.0/24 10.0.100.1 UGS ovpnc1
10.0.100.1 link#10 UH ovpnc1
10.0.100.2 link#10 UHS lo0
127.0.0.1 link#7 UH lo0
148.74.168.0/21 link#2 U bge1
148.74.175.197 link#2 UHS lo0
167.206.13.180 00:0a:f7:13:24:25 UHS bge1
167.206.13.181 00:0a:f7:13:24:25 UHS bge1
172.16.29.0/24 10.0.100.1 UGS ovpnc1
192.168.29.0/24 10.0.100.1 UGS ovpnc1
192.168.64.0/24 link#1 U bge0
192.168.64.1 link#1 UHS lo0
Work (server)
ejprice@ppt-fw:~ % netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 24.187.203.129 UGS igb0
10.0.10.0/24 10.0.10.2 UGS ovpns1
10.0.10.1 link#9 UHS lo0
10.0.10.2 link#9 UH ovpns1
10.0.100.0/24 10.0.100.2 UGS ovpns2
10.0.100.1 link#10 UHS lo0
10.0.100.2 link#10 UH ovpns2
24.187.203.128/29 link#1 U igb0
24.187.203.130 link#1 UHS lo0
24.187.203.131 link#1 UHS lo0
24.187.203.133 link#1 UHS lo0
127.0.0.1 link#6 UH lo0
172.16.29.0/24 link#12 U igb1_vla
172.16.29.254 link#12 UHS lo0
192.168.29.0/24 link#2 U igb1
192.168.29.251 link#2 UHS lo0
192.168.64.0/24 10.0.100.2 UGS ovpns2
192.168.100.0/24 link#4 U igb3
192.168.100.1 link#4 UHS lo0
I have tried both network topology settings. Currently, the server is set to topology subnet but I tried net30. I have no preference here, I just want it to work :)
Any help would be appreciated. I've been beating my head against this for a week now.
Cheers!
Ean
-
Hi Ean,
Please try this kernel:
# opnsense-update -kr 17.1-route
# /usr/local/etc/rc.reboot
If it doesn't work, you can then at least switch back to the old behaviour with:
# sysctl net.pf.share_forward=0
We have 17.1.1 coming up tomorrow for that reason.
Cheers,
Franco
-
Thank you Franco! I'll just wait until tomorrow for the 17.1.1 update. And I will stop beating my head against it and be happy that I'm not losing my mind :)
Btw - I absolutely love OPNSense. I've been hacking on OpenBSD firewalls for years and this is just so much nicer, easier and with batteries included.
Also - someone over there was supposed to email me a support contract but I never received it. Is there someone I can reach out to?
Thanks again!
Ean
-
Hi Ean,
Thanks for the kind works! :)
Some rough edges going from FreeBSD 10 to 11 which is a bit unfortunate, but we'll get through it.
Doesn't matter if you wait or confirm today, the kernel will be the same and a heads-up is appreciated. :)
I only do open source, not affiliated with Deciso, but I will try to let them know.
Cheers,
Franco
-
Well, unfortunately, I've updated the kernel and no luck. Then I tried the sysctl tuning and still no luck. I must be doing something stupid here.
-
Ean,
I missed the "16.7" does the same thing, sorry! In this case it should only be a configuration glitch.
Which routing direction isn't working exactly?
Cheers,
Franco
-
Hello,
I've got a similar problem. The OpenVPN server is running on a server in the datacenter (ESXi host + VM) and the client is running on an APU-Board. Both systems are running 17.1-amd64 (fresh installation on the ESXi host, upgraded from 16.7 on the APu Board).
The goal is to setup a site2site vpn to be able to access the ressources in the datacenter from the local networks and to be able to connect to the local servers from the VM's running on the ESXi host.
At the moment i am able to ping a virtual machine running in the datacenter from the vpn ip address of the APU board (but not from any other addresses of any other interfaces). Furthermore i can sent traffic from a virtual machine running in the datacenter to the vpn ip address of the APU board but not to any local ip (of the APU board).
Firewall Rules Datacenter (just for testing purpose)
- OPENVPN: Allow * from * to *
- LAN: Allow * from * to *
Firewall Rules APU (just for testig purpose)
- OPENVPN: Allow * from * to *
- LAN: Allow * from * to *
I don't know why this is not working and i don't have any more ideas. I checked the following things:
- FW rules (tried with from any to any allow)
- routing tables (remote subnets are shown on both appliances)
- local firewall of the devices
Furthermore i am confused about one more thing: There is no field "remote networks" at the openvpn config on the client side. I attached a drawing of the topology to the post.
Maybe someone has an idea?
Cheers,
Jan
-
Ean,
I missed the "16.7" does the same thing, sorry! In this case, it should only be a configuration glitch.
Which routing direction isn't working exactly?
Cheers,
Franco
I've been unable to figure that out. I'm attaching the server and client XML configs with extraneous and private info removed. Might just be a wrong setting that is easy for a second set of eyes to spot?
-
I just want to update this thread.
I opened a case with Deciso support. They validated that my configuration was correct. Next, they set up test machines on their side. What they found was that OpenVPN Peer to Peer (SSL/TLS) is indeed broken. They were able to get Peer to Peer (Shared Key) to work and that is the configuration I ended up going with, at least until TLS is fixed.
In summary, don't use Site to Site (SSL/TLS). Use Site to Site (Shared Key) until this issue is resolved.
-
same problem here with 17.1.8. I can ping from the client side, but no ping in the other direction. I found that the server is using the tunnel ip 10.0.8.1 and expect the client at 10.0.8.1. But the ip address assigned to the client is 10.0.8.6.
So i changed the tunnel network address and set the route at the server box manually...and it works.
-
See this post here: https://forum.opnsense.org/index.php?topic=3984.msg20878#msg20878
Try to add a Client exception with the remote subnet readded as already done within the server settings.