UDP traffic being blocked by default deny rule
-
Hello all,
I'm an RF and network engineer, and I'm working on a Motorola DMR IP Site Connect setup. It uses a master repeater in a colocation facility with a remote firewall with UDP ports 50000-50015 port forwarded to it from the internet. There are 4 other remote sites currently connected to it, and working great. These remote sites have no forwarding done.
I'm trying to setup a 5th site at my home using a Pfsense setup on a ProtectLi device.. My home Motorola repeater refuses to connect to the master site despite my best efforts when using Pfsense. I put the home unit directly onto the internet, and it connects and works fine. I have one of those GL Inet Opal travel routers that I use when I'm on the road, so I installed that instead, and works fine when using this firewall as well.
This got my brain going a little bit, so I tried Untangle on the Protectli, which I really don't like, but it worked, too.
So I got to digging a bit in my Pfsense setup, and found a ton of these messages in the firewall log. (IPs randomized a bit)
Dec 21 15:58:30 WAN Default deny rule IPv4 (1000000103) 47.111.214.96:50008 75.1.184.46:14041 UDP Dec 21 15:58:30 WAN Default deny rule IPv4 (1000000103) 216.11.194.172:50005 75.1.184.46:14041 UDP Dec 21 15:58:30 WAN Default deny rule IPv4 (1000000103) 216.41.194.172:50005 75.1.184.46:14041 UDP Dec 21 15:58:36 WAN Default deny rule IPv4 (1000000103) 47.111.214.96:50008 75.1.184.46:14041 UDP Dec 21 15:58:36 WAN Default deny rule IPv4 (1000000103) 216.11.194.172:50005 75.1.184.46:14041 UDPNow, in reading about this default deny rule, I found a lot of information about asymmetric routing here and here but these pertain to TCP connections. All I have is UDP. I mirrored a port on my switch and ran some WireShark captures, and I can verify that the traffic is going outbound just fine, but getting blocked inbound on the firewall.
I also see that there is a randomizing of the UDP port numbers, while I've noted this before, it hasn't caused issues, but maybe it is in this instance?
I've been beating my head against the wall for a couple of weeks now, so time to ask for some help.
As always, thank you in advance.
-
@Dillio
post firewall rules of pfsense, explain your network configuration pls (interface assigned etc)is it DR3000 in peer mode? ip assigned?
we need more information :) -
@kiokoman said in UDP traffic being blocked by default deny rule:
@Dillio
post firewall rules of pfsense, explain your network configuration pls (interface assigned etc)is it DR3000 in peer mode? ip assigned?
we need more information :)they are actually XPR 8300 and 8400s. Yea, they're old, but we have a pile of parts for them and they still work!
It is in peer mode with a static IP assigned, 192.25.1.27/27
The gateway is 192.25.1.1
I've tried DHCP as well, no change.network config is cable modem --> WAN port --> trunked VLAN port (igb2.25) --> trunk port on ProCurve switch.
I have a number of VLANs trunked from my internal network to the Pfsense for guest access, internal use, security system, phones, and IoT. The repeater is on the IoT network, VLAN 25.
The firewall rules themselves pertaining to this VLAN are very simple.
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0/714 KiB
IPv4 * VLAN25 net * * * * none IoT network internet accessMy WAN port rules (default out of box)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0/0 B
* RFC 1918 networks * * * * * Block private networks
0/70 KiB
* Reserved
Not assigned by IANA * * * * * Block bogon networksI've tried the repeater on some of my other vlans as well, and I get the same results
-
version of pfsense? do you have captive portal in any vlan ?
-
@kiokoman said in UDP traffic being blocked by default deny rule:
version of pfsense? do you have captive portal in any vlan ?
running the current version, 2.7.0-RELEASE
No captive portals. FWIW, I tried OpnSense on a spare device I had, same issue!
-
@Dillio said in UDP traffic being blocked by default deny rule:
running the current version, 2.7.0-RELEASE
that is not current 2.7.2 is current..
If you have traffic hitting your wan to port 14041, and you want that to talk to something behind pfsense. You would have to create a port forward.. Or your whatever is your trying to talk to behind pfsense would have to us UPnP open up the port. And you would have to enable that on pfsense. Out of the box UPnP is not enabled - it not a good solution. If you know the port, create your port forward.
-
@johnpoz said in UDP traffic being blocked by default deny rule:
@Dillio said in UDP traffic being blocked by default deny rule:
running the current version, 2.7.0-RELEASE
that is not current 2.7.2 is current..
2.7.0 still says current when I click for updates shrug
Is there some other repo that I should have installed or enabled?If you have traffic hitting your wan to port 14041, and you want that to talk to something behind pfsense. You would have to create a port forward.. Or your whatever is your trying to talk to behind pfsense would have to us UPnP open up the port. And you would have to enable that on pfsense. Out of the box UPnP is not enabled - it not a good solution. If you know the port, create your port forward.
That's the thing, the traffic shouldn't be hitting 14041. It should be hitting 50000-50015. That port changes randomly if I reload the firewall, too. I certainly do NOT want UPnP. These peer repeaters do not need port forwards into them at our other sites, 3 are using Fortinet firewalls, and one is using a Sonicwall, the connection is established outbound from the peer to the master. I think there is something strange going on here with NAT, but I can't put my finger on it or figure out what is happening.
-
@Dillio if you have traffic leaving out some other connection and returning to a different interface where there is no state.. then yeah it would be blocked.
-
@johnpoz said in UDP traffic being blocked by default deny rule:
@Dillio if you have traffic leaving out some other connection and returning to a different interface where there is no state.. then yeah it would be blocked.
I'm just not sure how that's possible. I don't have any special routing setup, in fact, if I take my backup hardware and load pfsense on it, and install it in place of my production one, the same exact thing happens with the only rule being added is an allow rule to allow internet access from the LAN side.
-
@Dillio said in UDP traffic being blocked by default deny rule:
47.111.214.96:50008 75.1.184.46:14041
You sure that is return traffic being blocked?
You sent traffic too 47.111.214.96:50008 from 75.1.184.46:14041, and that is your answer being blocked?
Or is that just some random traffic to your 75.address to port 14041 destination?
If you had created traffic to 47.x on port 50008 you should see that in your state table, if its not in your state table then no the reply would not be allowed.
What seems odd is you also sent to 216.11.194.172:50005 from the same source port 75.1.184.46:14041
If it was return traffic I would expect that to be from a different source port talking to a new IP.. on a different port.
edit: example here are some states to outside IPs via udp, on 443, notice the source ports from my IP different when talking to a different IP..
Seems odd to what you showing is blocked is actually answer to what you sent, seems more like unsolicited inbound to that 14041 port that you don't have a forward setup for and yeah would be blocked by default deny because its not returned traffic that matches up with a state you have created to it..
-
@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 -
@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.
@Dillio do you have some sort of static port outbound nat set?
-
well, there is nothing fancy about this XPR
there is a master listening
and a slave/peer that should connect to the master using udpthe network configuration should be like this image
next step is to check that every repeater have a unique RID
but it should create states between the peer and the master, i'm puzzled about that 14041,
neverthless they are known to have network problems -
@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.
-
@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.
