UDP traffic being blocked by default deny rule
-
yea that didn't change anything. The incoming traffic is still trying to go to 15452 right now (and 14041 previous et al). Why is NAT trying to change the incoming port? The master and other peer repeaters are set to only use their assigned UDP port.
-
I've noticed that every time I do a 'reset states' on the firewall, the port that gets reported in the log changes. Right now, it's 7323.
-
@Dillio And in your state table where did you create the connection too? I showed you example of states something behind pfsense creates..
Yes the port would change, but it would change for ever different connection, etc..
And i you make a connection to 1.2.3.4:portX, some traffic from 1.2.3.4:portY is not going to work, etc..
In my above state table you see my 192.168.9.100 create the outbound connection to the destination IP.. And then you see the outbound nat state that is created out the wan..
-
@johnpoz so is there no way to tell pfsense that it's legit traffic? That's what is being blocked and is what needs to be allowed. I don't understand how I can tell the firewall to pass that traffic when that port changes every time the states get reset.
-
@Dillio Your not understanding how a firewall works is my take..
If you create a connection to 1.2.3.4:port X, from yourIP:portA - the answer needs to come back from 1.2.3.4:port X to your port A.. If some traffic gets sent you from port Y its not going to work..
If you want to allow unsolicited traffic to something behind pfsense you have to create a port forward.. Some traffic that hits your pfsense wan IP on some port is unsolicated..
Look in your state table.. What did you talk to?? From my understanding of this application you should be talking to the master on some port.. The answer back from it would be allowed by the state.. But if some other clients of this master try and talk to you from other ports and other IPs and you didn't create the connections to them - then that would be blocked..
What exactly is not working? Or are you just seeing blocks in your log?
See here from my above state table
So 142.250.191.170 would send their answer back to that 56558 port from the 142.250.191.170 port 443, and that state would allow the traffic in and send it on to 192.168.9.100 port 56420..
If I got traffic from 142.250.191.170 even if was from 443 source port, it wouldn't be allowed back in unless it was to that 56558 port.
-
@johnpoz well I do understand how firewalls work, I do this for a living which is why this is baffling me so much, it makes no sense. I have built hundreds of networks using Fortigate, Sophos, Cisco ASA, and other firewalls. My repeaters are not sending traffic on these ports that pfsense is reporting. I'm not saying I know everything, but I'm not some new kid on the block, either. I've been at this since I got my first job at an ISP building dialup networks using 28800 bps modems in 1996. Now, what could be fair is saying "you dont understand the inner workings of NAT". That I contend is true
What isn't working is my repeater here at home is islanded from the network. I can key up my radios on it, and nobody can hear me. People on the other repeaters key up their radios, and I cannot hear them.
If I simply swap out the firewall for a product with another brand, everything works fine. If it were the case that my repeaters were sending traffic on these random ports, NOTHING I put in place would work.
I like pfsense, though, and would rather use it than something else.
This is my states table for the network in question. You can see that it's sending outbound traffic to 4 networks. One of the remote sites must be offline, so it's sending to 50000 (master repeater) 50005 (peer repeater), 50008 (peer repeater) and 50011 (my monitoring software connected on VPN)
-
@Dillio and where is your outbound nat state.. So while that source port is from 50004, unless you use static outbound nat, that will be changed to some random port. That is how napt works..
See my above posting.. see where the lan side state is port X, but when it leaves the wan its port Y.
https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#static-port
-
okay, I'm following you now. I was filtering my states table for my internal interface servicing the VLAN, so it was only showing what I posted above. I can see the traffic leaving the WAN interface with the random port when I filter by the WAN interface.
I was going down the path of setting a static outbound nat a few days ago, but it's not working so I can't tell if I'm doing it correctly or not.
Here is the current setting, which isn't working. What am I doing wrong with this rule?
-
@Dillio yeah that would work for anything going to those ports.. So now on your wan outbound what do you show for your source port as it leaves the wan?? I would assume your 50004 if its working..
-
@johnpoz it's still showing the randomized ports.
-
@Dillio said in UDP traffic being blocked by default deny rule:
it's still showing the randomized ports.
Well then its not working, you would have to make sure you create new states..
When you set a static port like that, the source port leaving pfsense wan would/should be the same as the source port from your client..
The problem I have with static ports.. Is if client X is using source port X, and pfsense uses X as source when it leaves.. you can't create another source port leaving pfsense on X, etc.
But when you set that - your states should look like this
Notice the source port used by the client, is the same source port used when leaving your wan.
edit: So your saying its working now? Before you showed making connections to clients, but got no answers..
You only showed 2 way data on your connection to port 50000
-
@johnpoz I will bounce the states on the firewall. My wife is working from home today (of course) and has been notified and will give me a window to do so in a bit.
-
bouncing the states did the trick along with the outbound NAT rule. Of course, nobody is around to answer a radio call, but I'll get to that tonight.
Thank you for working through this with me. I've never had to do this before to get a radio site working, but all firewalls aren't built the same and this is just a little quirk that I'll have to document for the future.
