Single NIC setup blocks TCP traffic besides ANY rule
-
Hello,
First of all, thank you for making it possible to post my question here.
I am new and desperate because I stuck my head into this issue a while now and it is not getting any clearer.Here is my problem:
We use a pfSense as a client-VPN entry-point for our business.
This pfSense is hosted on a cloud-server and connects with our WAN via IPsec to one of our sites. For our clients, we use OpenVPN via 443/UDP.As we do not have any other services in the same cloud, we only need one NIC, which is configured with a private IP given to us via DHCP from the cloud-hoster. We also have a public-IP which is forwarded to us.
The firewall is configured completely open regarding IPsec and OVPN, as we are handling restriction on the site-firewall, not the pfSense.
This did work for some time now, flawlessly even. However, we had to change the public-IP of the Site the IPsec-tunnel is connected to and therefore needed to change the IPsec-settings as well. The tunnel came back up without issues, but soon our OVPN-clients started to complain about certain programs not running. Upon further inspection, we noticed that only TCP services did not work, because they were missing half of their packets, constantly.
After checking the firewall, we noticed that it was blocking said packets, even though they were fitting the requirements and were actually parts of a ongoing session. I have no idea what's going on.
I did scetch a short picture to make things clearer:
//cannot post due to it being marked as spam...Maybe some of you have a clue where to look?
Thank you,
Max
-
-
Just as a further thought:
I think this might have something to do with asymetric routing, because a lot of posts with similar errors go in the same direction. But I am wondering how, as this setup shouldn't be able to loop in any way.
-
@maxtheitguy
Why do you hide private IPs (+ ports!)? No one here will be able to access them in any way.Without any clue of your network, IPSec and OpenVPN setup and the routing table of pfSense it's hard to say, what's going wrong.
Which services do the VPN clients access?
Is the access routed to the site? Are the connections natted? -
Sorry, this was indeed maybe a bit too precautious.
I just dislike showing IP patterns, sorry about that.The ports are actually all over the place and quite interesting.
Some of the dst ports in those logs are dynamic ports from ongoing connections.
Hence my idea about it being about asymetrical routing and splitted sessions.
As a test, I created a floating any-rule and set the state type to "none".
After that, all those deny-entries changed to accept, but the issue still persists for the clients.About your other questions:
All 172.19.X.X Clients are OVPN-Users connecting to the pfSense to access any other part of the network (Those other parts are the networks 172.17.X.X/172.18.X.X)
There is no server or anything else in the cloud for the user to access, just this pfSense.Which services do the VPN clients access?
- Everything from HTTPS, SMB to RDP or DNS. UDP does currently work, TCP does not.
Is the access routed to the site?
- All internal traffic is routed to the site and from there to its destination.
- External Web-traffic is not handled by the OVPN.
Are the connections natted?
- There is no NAT used internally. But the IPsec is built on the Port forwarding of the Cloud-Hoster.
If there is anything else I should paste in here, please tell me.
Do you need a copy of "Diagnostics/Routes" for further understanding?Thank you for your help!
-
Also, this should not be possible, right?
172.17.1.27 is a Server on the IPsec-Side, not an OVPN-client.
Why did this appear as src on the ovpns1 Interface...