(solved) pfSense blocking nomachine connections without reason
I never used pfSense 1.x.x so I'm not sure if the problem exists there. Feel free to move this thread to a more appropriate section if it's not 2.0-RC related.
I have a pfSense setup to replace our old Zywall35 setup. Because the Zywall did not have enough LAN ports I had two extra gateways in my LAN subnet. One of these is a MPLS VPN line to another location. Ultimately this GW will be moved to another network card but not until I'm sure the below problem is solved.
pfSense 10.10.0.5 –------------ Client 10.10.7.101
--- MPLS 10.10.1.6 ------- VPN ----- nomachine server 10.9.1.101
The default GW of the client is pfSense 10.10.0.5. There I have a static route 10.9.0.0/16 via GW 10.10.1.6. I have firewall rules on the LAN subnet to allow traffic from the LAN subnet to the remote subnet and to make sure I made another rule doing the opposite.
Client route to email@example.com:
Tracing route to 10.9.1.101 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.10.0.5
2 <1 ms <1 ms <1 ms 10.10.1.6
8 23 ms 23 ms 23 ms 10.9.1.101
Hops 3~7 are the VPN subnets.
Now when I open a connection to the nomachine server it starts just fine and I can work with it for a minute or so, then the connection is dropped. Checking the log of pfSense, it appears pfSense is doing the dropping although technically I don't think that pfSense has anything to do with the connection other than pointing the way (route) for the client, since the client and the GW are in the same subnet.
A dump of the pfSense FW log is attached as image. The connections is first allowed, then later connections are blocked.
When I change the "Firewall Optimization Options" from normal to conservative I can work a little longer with nomachine but the connection still terminates. When I change the clients default GW back to the Zywall (thus not using pfSense in the route) the connection never terminates.
Which setting in pfSense did I forget?
Any help appreciated.
Sacrilego last edited by
I experienced the same issue but worked around it.
I had pfSense and a Cisco router on the same LAN subnet, it would randomly drop the connection to the remote network on the cisco router after a small period of time.
The logs show that packets were being dropped.
Just like you, I don't see why it should. I can only guess that pfsense is actually routing the packets for the client instead of redirecting the client to the other router.
This worked fine before I replaced our aging router.
pfSense LAN 10.10.1.1/16
Cisco LAN 10.10.1.5/16 –-------- T1 ----------- Cisco Remote 192.168.1.1/24
I worked around it by moving the Cisco router to it's own subnet and adding the new interface and static route on pfSense.
Using 2.0 RC built on Tue Mar 29 13:39:02
The logs show that the blocked packets are "return" traffic, that is traffic trying to go back to the other side in reply to packets received.
Normally seeing such packets indicates one of two things:
- You have asymmetric routing, where traffic is taking a different path back than the way it left, so it doesn't match the existing state
- The existing state was removed for some reason, causing the packets to be dropped.
I'll move the MPLS to it's own interface/subnet next week and will keep my fingers crossed.
When moved there shouldn't be any chance of a async routing so that should solve the issue.
Solved by moving the MPLS gateway into its own subnet/interface