UDP traffic being blocked by default deny rule
-
@Dillio said in UDP traffic being blocked by default deny rule:
It is in peer mode with a static IP assigned, 192.25.1.27/27
so it's not the master and no nat should be needed
idk if the other peer need to talk to each other but ...
@Dillio said in UDP traffic being blocked by default deny rule:
There are 4 other remote sites currently connected to it, and working great. These remote sites have no forwarding done.
for some reason pfsense is not registering the states?
i would exclude a bug at least not present on 2.7.2, i've made a test between my two pfsense and i can send to port 50000 and receive back an answer and a state is opened -
@kiokoman said in UDP traffic being blocked by default deny rule:
for some reason pfsense is not registering the states?
If that was the case nothing would work..
-
@johnpoz said in UDP traffic being blocked by default deny rule:
@kiokoman yeah that seems pretty straight forward.. So his device should be connecting to "master" unless he is the master? If he was the master he would need to port forward the port the remote devices would be using to connect to the master.
If he was just a client there really is nothing to do with pfsense, since the client would make a connection to the master IP And the return traffic wold be allowed via the state.
Do peers trying to talk to other peers? If so some peer trying to connect to a peer behind pfsense, pfsense would need a port forward. To allow other peers to create connections to the device behind it.
sorry for the late replies, busy with Christmas and all.
The master is at a colocation facility, not here at my home. There IS port forwarding at the master site, ports 50000-50015. Each peer repeater is programmed with the master repeaters UDP port (50000) and a UDP port of their own, this one happens to be 50004. The other repeaters are on 50002, 50006, 50008, and 50010.
Earlier you asked if I'm doing any custom NAT'ing. Well, not right now. I have tried to setup a hybrid NAT rule just for this repeater using this how to link text but that hasn't changed anything.
"
@Dillio
can you ping the XPR from the same or from another network? just to be sure that the network card is working
if it's a /27 did you set the correct subnetmask ? 255.255.255.224 on the XPR ?
maybe try to change the port
Someone with the same problem solved using port 55000
"Oh yes, I can put a laptop on that subnet and ping it no problem. I can ping it from the pfsense box, too. The mask is correct on the repeater. Interesting about port 55000, I wonder what would do that? Weird!
@kiokoman so you know more about these things - do they send what port the other end should answer too? If that was the case is it trying to do some sort of stun to get in, or does a port forward have to be setup for what port he end device sends to the other one to use?
If a state was created and still there when device A talked to B then the return traffic would be allowed. That doesn't look like normal return traffic to me because pfsense wouldn't normally be using the same source port that 14041 to talk to multiple IPs on different ports.
I think they do talk to each other on the other port numbers, as I'm seeing the other peer repeaters try to connect to me in my logs on their various ports. In addition, I have a "monitoring" program that I can open to see what is connected (it's using UDP 50011 and connects to the master) and when I open that, I get a TON of the same denied messages in the pfsense log from the machine hosting the monitoring program to the repeater inside my networking using 50004, so the master must be telling the peers where to look for the other peers.
If a state was created and still there when device A talked to B then the return traffic would be allowed. That doesn't look like normal return traffic to me because pfsense wouldn't normally be using the same source port that 14041 to talk to multiple IPs on different ports.
I don't even know where the firewall was getting 14041. Now it's on another port, 15452. Like it's picking them at random or something..
Dec 26 15:47:32 WAN Default deny rule IPv4 (1000000103) 47.111.214.96:50008 75.1.184.46:15452 UDP -
and for the record....this repeater works fine if I replace my pfsense firewall for my GL-Inet travel router with WAN/LAN ports. I don't think it's the repeater itself, it's something odd with pfsense and opnsense's NAT.
-
@Dillio said in UDP traffic being blocked by default deny rule:
this one happens to be 50004.
Well if your talking to IP 1.2.3.4 on port 50000, and you get a reply even if from the same IP but from port 50008 pfsense is not going to allow that because your state would of been to the IP with destination port 50000.. So the answer would have to come from that port for it to work.
If the other peers try and create a conversation with your device on whatever last port you talked to the master with for example.. Then they would send to that port, possible where the 14041 came from.. But again unless you did a port forward, and or you had started a conversation with them, so there was a state that traffic would be denied.
-
@johnpoz said in UDP traffic being blocked by default deny rule:
@Dillio said in UDP traffic being blocked by default deny rule:
this one happens to be 50004.
Well if your talking to IP 1.2.3.4 on port 50000, and you get a reply even if from the same IP but from port 50008 pfsense is not going to allow that because your state would of been to the IP with destination port 50000.. So the answer would have to come from that port for it to work.
If the other peers try and create a conversation with your device on whatever last port you talked to the master with for example.. Then they would send to that port, possible where the 14041 came from.. But again unless you did a port forward, and or you had started a conversation with them, so there was a state that traffic would be denied.
For S's and G's, I'll setup a port forward to see what happens. If it works, I'll just leave it in place, no skin off my back.
-
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.
