2.1.5 -> 2.2: Wrong source IP (filter logs)?
-
Hi,
I've upgraded to 2.2RC over christmas and found it to be a bit strange:
My #1 concern ATM is seeing strange behavior behind a primary router (cable provider, can't avoid that) that is configured to route all incoming traffic (exposed host) to pfSense's WAN interface. That has worked fine in the past. But now my pfSense Logs are flooded with block entries that ALL come from my own external WAN IP (the one I actually have connected to the internet on the WAN side of the cable router) and to pfSenses internal WAN IP
<ext. ip="">(WAN - cable Router - LAN) 192.168.178.1 <==XFER NET==> 192.168.178.2 (WAN pfSense LAN) 172.x.y.z (internal LAN)
Logs look like that:
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:31271 | 192.168.178.2:43256 | UDP
…
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDP
WAN | default deny rule IPv4 | <ext_ip>:59806 | 192.168.178.2:43256 | UDPInstead of the other "normal" traffic blocks I'd see over the day, my log's spammed with those.
Was that already discussed somewhere?
Other than that that's a pretty "normal" easy home/lab setup without packages or other stuff.Greets</ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext_ip></ext.>
-
If you have a cable modem/router combination unit (commonly called a gateway device), you might want to contact your cable provider and see if they can put it into Bridge Mode, or look through the settings and see if you can do it yourself. In Bridge Mode, it will act as if it's only a modem, allowing you to connect your pfSense box directly to the internet rather than using a DMZ forward like you are now.
-
If you have a cable modem/router combination unit (commonly called a gateway device), you might want to contact your cable provider and see if they can put it into Bridge Mode, or look through the settings and see if you can do it yourself
Thanks, but my request is "what changed" and if that's now normal behavior. Falling back to 2.1.5 shows "normal" traffic to WAN with original IP addresses and all. Only 2.2RC (latest, 64bit, NanoBSD) shows that strange logging phenomenom.
I can't and won't change anything on my cable box, as that is provider handled and "subject to change" as I can't control it to 100%. As this is a german cable provider, there is nothing you can do about your connection otherwise, so thanks for mentioning bridging mode, but I've already tried that years ago. As this is a consumer link there's no way in hell they'll hand you either static IPs nor bridging mode on their router (which is an AVM FritzBox Cable 6360 BTW).
Anything else I'm missing? The FB is still handling connections/1st NAT like before so it's strange I don't see those packets arriving from their original destination as before. Also I don't get it why it is literally "bombing" the new 2.2 pfSense with UDP packets where no process is listening. It's always bursts from one source port to the FW on a UDP link, then another burst from another source port but with same destination UDP port. Anyone else seeing phenomenoms like this?
Greets
Jens -
I have other strange readings to report:
With 2.1.5 I had double NAT running behind the cable box without problems. With 2.2 I now have really big trouble with traffic not arriving (IPv4) on the external WAN interface of pfSense or not being recognized.
2.1.5: connecting from a server to my exposed pfSense behind the cable box to a port like 12345 -> hit shows up in firewall filter logs as blocked (OK)
2.2RC: same as above isn't shown in filter logsI could live with that meaning filter logs won't get too spammy (but that's what those switches for log all blocks etc. are for -> I want to see them).
BUT:
2.1.5: Port forwarding for tcp/5001 -> NAS Box inside my LAN => working fine (and logging pass hits)
2.2RC: same as above WON'T work, getting no connection through the NAT nor the connection logged or showing even up as a state.As it seems to me, there is something really wrong in this configuration being it as simple as it should but I don't see where the troubles come from. The configuration was done like before and isn't that hard. Simple WAN static IP, LAN static IP, advanced outbound NAT, Port forward and it should work. But it doesn't and instead shows all kind of crazy side effects…
Any help? Anyone?
Greets
Jens -
Without real details i can guestimate the advanced outbound NAT to be the issue.
-
Hi ermal,
nothing out of ordinary there:
Switched to "Manual Outbound NAT rule generation, (AON - Advanced Outbound NAT)" and have the two 127.0.0.1 rules along with my two internal LAN rules there. Completely default. I already switched static port to "on" as that's needed for NAT type 2 on Sony devices like PS3/4 but other than that there are no changes from default regarding routing, NAT etc.
Only thing I have running out of the ordinary is a HE.net IPv6 tunnel that behaves quite normally.If you'd like to point out, what you would need, I'd happily supply informations (as this is my home & lab setup) but ATM I'm on the verge of throwing in the old CF card with 2.1.5 back in as it's really strange.
I'm also testing from an external server I have with a static IPv4 & IPv6. I configured a port forwarding to my internal NAS for that server on WAN -> won't work. I don't even see it coming. Using NC/telnet to e.g. port 12345 I don't see a block on that port. If I do the same via IPv6 I see that port blocked incoming from the v6 address from said server. So that would be the correct result. I already checked the settings on the cable router up front but nothing changed there since updating from 2.1 -> 2.2 and it worked flawlessly before.
Greets
Jens -
Seems I have figured out what the second part of the problem was. I got the "port forwards not working/no v4 pakets arriving on WAN".
Still hitting the first part of the puzzle (see first post). Those UDP logs are still hitting.