Unexpected blocked traffic
-
Hi,
I'm rather new to pfSense and just set everything up.
The setup is the following:VPN –------------
|
WAN ---- ISP router ---- pfSense ---- LANISP router: 192.168.0.1
pfSense WAN: 192.168.0.21
pfSense LAN: 10.0.0.1
LAN: 10.0.0.x
VPN: is OPT1, hands out 10.10.10.xpfSense is routing outgoing traffic through the VPN (OpenVPN) and overall, it is working fine.
However, my firewall log gets spammed by entries, I am not totally sure why they are there.
Looks like this.1.) The IPv6 traffic.
IPv6 is disabled on every interface.
The blocked fe80 addresses are local computers (fe80::5a23.. is the ISP router).Why does IPv6 even reach pfSense, what is it trying to do there and how do I get rid of the log entry?
2.) LAN to WAN.
Why does LAN->WAN traffic show up as blocked?
It did notice this post, which has the same problem but no solution yet.3.) The traffic on OPT1.
OPT1 is a OpenVPN endpoint. The IP address is dynamic/shared and there should be no portforwarding.
Is this the same problem as 2.) but in reverse? No one should be able to even reach pfSense from the outside. -
- IPv6 still happens in pfSense - it is just that it only has link-local address(es).
Status->System Logs, Settings
Log packets matched from the default block rules put in the ruleset - you can turn that off, which will get rid of the general block logging for both IPv4 and IPv6.
Then put your own explicit IPv4 block rule on LAN with logging for anything you would like to log.
or, leave the setting on, and put an explicit IPv6 block all rule on LAN with no logging.
-
LAN to WAN - states are started by a SYN packet. If a packet comes along that does not match an existing state and is not a SYN packet then it is always dropped. That is stateful firewall behaviour.
States time out after some period. If a packet in the client<->server exchange got lost for a while and comes along after the state has timed out, or after the connection has been closed (FIN packet gets ahead of some other packet for some reason…) then these "stray" packets will be blocked. It is normal to see some of these. -
Similar to 2. That is a "late" packet for a state that has timed out. Interesting that the NAT for the state is still there, because it has "unNATed" the packet coming back from the real internet before blocking it.
- IPv6 still happens in pfSense - it is just that it only has link-local address(es).
-
Thanks for the reply.
If we take a look at the block in the middle of the first picture, where 10.0.0.10 tries to send data to 91.190.218.59:
- there was an established connection, which got interrupted somehow
- 10.0.0.10 sends data for 10 seconds (psh,ack)
- 10.0.0.10 doesn't get any response and want's to close the connection (fin,ack)
- 10.0.0.10 doesn't get a response and resets the connection (rst,ack)
Is this right?
I did also notice, that the log gets flooded with these messages, if the VPN connection resets.
It tries to send data to the old virtual IP.
I can stop it by restarting my local network device (the one from the windows network center). -
The packets that are a couple of seconds apart are probably just retransmits of the same packet, which would happen because the client never receives an ACK (since the packet got dropped at the firewall). Then the client will give up and try to send a FIN to close the connection, which is also blocked.
When the VPN connection resets, pfSense is going to do some state cleanup. So those states have been removed and thus the leftover traffic does not match a state and is dropped.
I guess that is life when a link (logical or physical) goes down and then reestablishes - new states/flows have to be established over the new link.