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..
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.
-
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.
