Traffic arriving on OpenVPN interface not being routed forward
-
I've got a SG-3100 running pfSense 21.05.1 that is a VPN client to a virtual pfSense in a datacentre that no matter what I try, the sg-3100 doesn't forward packets to devices on its LAN. The traffic seems to stop at the OpenVPN interface even though the traffic is allowed on OpenVPN interface as from any to any. I tried being more specific with the rule but still I get the following:
ovpnc1 udp 10.10.100.6:62223 -> 192.168.1.12:161 NO_TRAFFIC:SINGLE 1 / 0 107 B / 0 B
ovpnc1 udp 10.10.100.6:62223 -> 192.168.1.15:161 NO_TRAFFIC:SINGLE 1 / 0 107 B / 0 B
ovpnc1 tcp 10.10.100.6:55518 -> 192.168.1.12:80 CLOSED:SYN_SENT 3 / 0 152 B / 0 B
ovpnc1 tcp 10.10.100.6:55519 -> 192.168.1.12:80 CLOSED:SYN_SENT 3 / 0 152 B / 0 B
ovpnc1 tcp 10.10.100.6:55520 -> 192.168.1.12:80 CLOSED:SYN_SENT 2 / 0 104 B / 0 BAll connections have packets as sent to the interface, but I guess they not forwarded further down to the devices on its LAN. No traffic is being blocked at firewall level.
This is really weird, I've been using pfsense for years across tons of different netgate appliances, I never had an issue like this, OpenVPN is such an easy thing to get working. If I put a VM pfsense in place of this physical sg-3100 to test the same network configuration it all works fine.
What do you guys think that is the issue?
-
Hmmm...so on both pfSense appliances do you have the IPV4 Remote Network(s) under your Tunnel Settings setup so they get to the right place?
For example:
pfSense OpenVPN Client
IPV4 Remote Network(s): 192.168.1.0/24pfSense OpenVPN Server
IPV4 Remote Network(s): whatever your subnet is for your LAN / whatever your Subnet Mask is for your LAN. -
@thatguy said in Traffic arriving on OpenVPN interface not being routed forward:
Hmmm...so on both pfSense appliances do you have the IPV4 Remote Network(s) under your Tunnel Settings setup so they get to the right place?
For example:
pfSense OpenVPN Client
IPV4 Remote Network(s): 192.168.1.0/24pfSense OpenVPN Server
IPV4 Remote Network(s): whatever your subnet is for your LAN / whatever your Subnet Mask is for your LAN.correct, I've got the ipv4 networks stated on each side plus the virtual network between the two, I've done this hundreds of times so I was quite puzzled that it didn't work this time. As soon I spun up a VM running pfsense and did the same config by hand, it all worked fine so I isolated this to the SG-3100 appliance. I then tested backing up the sg-3100 config and restoring to a VM, that didn;t work well at all, the firewall could not even route anything to the internet after I reconfigured the WAN, really strange. Maybe configuration from an ARM CPU and pfsense+ cannot be recovered to a VM running x86 and community edition?
It is really weird, and the only time I had something really odd happening with pfsense a few years ago with a SG-1000 I had to re-image the device to work properly as nothing else manage to make it work.
Just to summarise my config:
VPN server LAN 10.10.100.0/24, VPN network 10.254.51.0/24 and remote network 192.168.1.0/24
vpn client LAN 192.168.1.0/24, VPN network 10.254.51.0/24 and remote network 10.10.100.0/24Firewall rules allowing traffic on the openvpn interface on both firewalls, tested from any to any to specific rules.
VPN client can ping and access things on the VPN server network, but VPN server network cannot see anything on the VPN client network. Sessions on VPN client network all show packets under stated on the openvpn interface as received, but I guess not forwarded to destination. When I run the same configurtion done by hand on a VM replacing the role of the VPN client, everything works fine and under states I can see the packets being received and forwarded to the destination.
I'm really puzzled with this, it sounds like a bug with pfsense. Not the first time I see some weird stuff like that that you need to clear the states, or at times only a reboot makes it work. In this case, nothing makes it work on teh SG-3100
-
Are you using the exact same versions of pfSense on both the SG and your other appliance(s)? I have seen issues when mixing and matching pfSense versions where stuff doesn't route back and forth via OpenVPN. I don't think it's necessarily a pfSense version issue. I think it's an OpenVPN version issue within pfSense....but I could be wrong.
At my company we set up tons of OpenVPN Servers with a tutorial. I wrote and have revised that tutorial as new pfSense versions have been released. Whenever a tech sets one up and it doesn't work I always tell them, "You've made a mistake. Wipe out everything and start over and go through the tutorial step by step paying close attention to every detail." It always works the second time and typically when they go back through the tutorial they catch their mistake. Heck, I've set up tons of OpenVPN Servers and I still use my click and drool tutorial so I don't screw something up.
Had one guy put the remote tunnel in as 192.168.5.1/24. I looked through the settings forever trying to find his mistake and I missed it to. But when he went through the tutorial again he realized it should have been 192.168.5.0/24.
-
@thatguy I've reinstalled the firmware, it is all working fine, exactly same configuration sone as before.
I also agree that 99.99% of times it is human error configuration, but I checked everything 10 times and re did the configuration about 10 times, once I reflashed it, it worked just fine.
-
If you really want to find your mistake, export both of the configs from the working pfSense appliance and the non-working pfSense appliance. Open the two xml configs in Notepad++. Use the compare feature in NotePad++ and you can usually find the difference pretty quickly in both configs.
-
I've run into a similar issue, also having many other instances working in the field.
The problem that I can see is that the iroute works, within the openvpn space, but the OS underlay is not adding the route, so traffic doesn't go back.
If you raise the log level to 6 and grab the logs, you'll see if your iroute gets installed, then ssh into the pfsense os and perform netstat -rn, you'll se if the OS has the route.
Still haven't found a solution myself.