Firewall dropping traffic that should not be dropped
-
Having a bit of trouble….
I have a small network
10.10.1.0/24
10.10.2.0.24There is a VPN to this network and the vpn clients are
10.10.10.0/24I have a few remote clients at 10.10.10.102 and 10.10.10.103 that connect to an internal box at 10.10.1.4 (and 10.10.10.104 for the vpn interface)
Firewall rule that allows the VPN connection works. VPN connected.
I added a gateway, and a route for the 10.10.10.0/24 network...
From my remote client (10.10.10.102) I can access 10.10.1.3 but I cannot access 10.10.1.12. The firewall log shows drops.
I have the default firewall rules that allow LAN to access anything.
I rebuilt the pfsense box from scratch and get the same problems... so I'm at a loss that just this one box is not able to get through.
-
You fail to mention what kind of VPN you are using and what device is terminating the VPN.
-
You fail to mention what kind of VPN you are using and what device is terminating the VPN.
I really didn't see how it mattered as I'm only having trouble accessing a single box on the network and you can clearly see the firewall dropping packets from a range within the rules that should be allowed, but it is a Tinc daemon running on a debian server.
-
Does the 10.10.1.3 box have a direct route to 10.10.10.0 that the 10.10.1.12 box does not? Do they have the same default gateway? Does the firewall have a route back to 10.10.10.0 via 10.10.1.4?
Try checking the box for 'static route filtering' under advanced, firewall. -
Does the 10.10.1.3 box have a direct route to 10.10.10.0 that the 10.10.1.12 box does not? Do they have the same default gateway? Does the firewall have a route back to 10.10.10.0 via 10.10.1.4?
Try checking the box for 'static route filtering' under advanced, firewall.The route for 10.10.10.0/24 only exists on the pfsense box.
Same default gateway.The route exists on the pfsense box.
root@10.10.1.12:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.10.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 25.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 ham0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.10.1.254 0.0.0.0 UG 1 0 0 eth0 root@10.10.1.3:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.10.1.254 0.0.0.0 UG 0 0 0 eth0 10.10.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0From 10.10.10.102 I can traceroute to both boxes as I would expect.
Aaron@boxen ~ $ tracert 10.10.1.3 Tracing route to 10.10.1.3 over a maximum of 30 hops 1 50 ms 49 ms 53 ms 10.10.10.104 2 60 ms 54 ms 69 ms 10.10.1.3 Trace complete. Aaron@boxen ~ $ tracert 10.10.1.12 Tracing route to tower [10.10.1.12] over a maximum of 30 hops: 1 51 ms 48 ms 50 ms 10.10.10.104 2 50 ms 48 ms 50 ms tower [10.10.1.12] Trace complete.I check the "static route filtering" box and things are working… Which I understand because it's bypassing firewall rules... but it seems that it should work without doing that... Why is the firewall logging dropped packets where there is obviously a rule that allows the traffic?
-
It may be due to the states being asymmetric as the remote traffic is coming in from the tinc server, then going direct to the LAN IP while the LAN machine send the response to the firewall, which sends it back to tinc. If you don't like doing the bypass, you could try making a rule for the traffic with state set to none.
-
It may be due to the states being asymmetric as the remote traffic is coming in from the tinc server, then going direct to the LAN IP while the LAN machine send the response to the firewall, which sends it back to tinc. If you don't like doing the bypass, you could try making a rule for the traffic with state set to none.
That does make sense. I don't understand however the problem only happens to this one physical host on the network (10.10.1.12)
For what it's worth;
10.10.1.12 is a physical host (with "the problem")
10.10.1.3, 10.10.1.4 (vpn server) are virtual machines running on 10.10.1.12 and don't have any problems. Might be some funny business there with the nic bridging, etc. Yeah? -
Connecting to a vpn endpoint that is inside the network vs the edge always comes with issues. Your traffic is blocked because its out of state. See the SA flag..
Isn't there a tinc package for pfsense, just run it on pfsense so the endpoint is your edge would make your life easier I would suspect ;)
-
Connecting to a vpn endpoint that is inside the network vs the edge always comes with issues. Your traffic is blocked because its out of state. See the SA flag..
Isn't there a tinc package for pfsense, just run it on pfsense so the endpoint is your edge would make your life easier I would suspect ;)
I'm planning on moving tinc to the pfsense box or going with OpenVPN - the tinc daemon in a virtual machine has been around for a long time and the pfsense box is new. Thanks for the help everyone!
