pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs
-
@johnpoz TRUE
NAT not working is the trigger. By investigating that, I have found all the additional info presented here.
So, why I can capture and DST-NAT the traffic on any other box I have here on hand, just not with the SG-1100 ?
Same config, same wires, repeated tests... and the SG-1100 passes the wan-lan traffic for the users (internet browsing from a LAN side)...I was afraid that there is some pre-filter or such, that would remove the packets before the Packet Capture, is that possible ?
I'm puzzled.
-
pfBlockerNG off, this is all that shows up in there now:
yet no activity
Seems like I'll first need to figure out why the SG-1100 box is not getting the TCP 8080 traffic.
I was afraid it is due to some (FW ?) rules, well is that possible ?Tried to re-connect WAN, even to renew to get a different IP... no difference
-
Make sure the device in front of pfsense is truly sending the traffic to the pfsense WAN address.
You have shown at least two different WAN addresses to this poing.. .99 and .55
-
@icansoft said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
that would remove the packets before the Packet Capture, is that possible ?
No... If your not seeing the packets on pfsense with packet capture.. Your either sniffing on the wrong interface or traffic is not getting there. Do you see the outbound and return traffic on this sniff?
-
@chpalmer
the .99 and .55 are two consecutive assignments by ISP's DHCP server, as I have renewed it during testing.
Good catch, but this unfortunately is not the issue.@johnpoz
sniffing on WAN (by pfSense system), seeing all the various traffic but none of the TCP 8080 which gets generated by various test tools (like the internet's port forwarding tester).
Unfortunately I do not own HUB for 100Mbit network to see what is on the line. So I have only the pfSense as a direct capture, or I can do indirect capture by replacing pfSense by Mikrotik or my notebook (wireshark). On both I do see the TCP 8080 traffic, once triggered of the Internet by the test web tool.Would that ever be possible that the UBNT client (UBNT bullet) "detects" that it has a pfSense box connected and selectively decides not to send a TCP port 8080 flow to it ? and once the pfSense box is replaced with anything else I have on hand, it suddenly works ? why, how ?
I think I'll go for a complete fresh reinstall. Can't come up with anything else on the pfSense box.
OK one more test, to disconnect the pfSense from ISP and to connect it to a simulated ISP (by my local standalone router). This might show some hints.BTW. thanks guys for helping out, appreciated, +1 karma
yet I'm puzzled ... what is going on -
So how would someone on the outside such as one of us get you your box? How does your ISP know to send that traffic to your box?
-
@chpalmer by going to a specific public IP (a.b.c.d), which the ISP routes through their system down to the POP where I'm connected. That is the UBNT Bullet wifi client, which provides the 192.168.1.1/24 network.
If I connect the Mikrotik router to it (WAN side of the router), setup the textbook Mikrotik's DST-NAT for the 8080, it works like charm and by going a.b.c.d:8080 (like via my LTE phone), it shows the correct webserver's output.
The webserver (rPI) is on the LAN side of the Mikrotik (subnet 192.168.2.1/24).I hoped to connect the webserver to pfsense box LAN and have the pfSense to DST-NAT the same way as the Mikrotik does (but without having the Mikrotik in there).
Which shall be doable by just switching the Mikrotik and pfSense in place, and configuring it properly.
And this is where I failed... it seems
For the LAN->WAN part the pfSense works like a charm, including the pfBlockerNG, and I can browse the web.
But the opposite direction, no joy. -
Here is what I tell every user that is having issues with pfsense forwarding.. Go to can you see me, put in the port your trying to forward on pfsense... If you don't see it on pfsense wan, then just plain impossible for pfsense to forward what it never sees.
-
All I read up until now is "other boxes do it fine" etc etc.
What I don't read is: How the hell is the ISPs UBNT Bullet WiFi thingy that gives out a private IP space (.1.1/24) and does DHCP getting to know it should forward anything at all to your changing DHCP address where you put pfSense at?I've not read anything how the upstream box is configured up until now. If I've missed it somehow I apologize but how should traffic to any external WAN IP, that gets only forwarded to your ISP endpoint POP (the UBNT box) get to a router afterwards without any settings on the UBNT side to actually forward anything to an IP? And a dynamic one nonetheless? That doesn't make sense to me.
-
Here is what I tell every user that is having issues with pfsense forwarding.. Go to can you see me, put in the port your trying to forward on pfsense... If you don't see it on pfsense wan, then just plain impossible for pfsense to forward what it never sees.
I hear you man, this was the first thing I've done, before ever posting this. But it got so wierd I had to - see as I wrote about the other routing working fine in there and pfSense nada. Quite a mystery worth figuring out.
So I've run a following test:
Disconnected the pfSense box from ISP and connected it to a plain standalone router LAN (which simulated the ISP / Internet), set up just for this test, with a factory reset done.
To the same router's LAN (another switch port) I've connected a notebook.
The pfSense WAN got assigned 192.168.88.253.
So, off to the browser on the notebook, type 192.168.88.253:8080, and boom voila, the web server page is served !So to conclude
- the initial issue - no NAT action for my setup - brought me so far
(thanks for keeping up with me, appreciated) - I definitelly have to agree, due to the final test, that pfSense NAT works OK, including the pfBlockerNG
(confirming the moderator's posts above), and I'm glad the issue is most likely not in there specifically, ufff - all the other boxes are OK and are doing the NAT thing, with the way the ISP is configured, just the pfSense is not
I'm grateful for all the comments, which helped to lead me to figuring this out. Thanks.
I suppose this thread might get moved to a different topic than NAT then.
@JeGr unfortunately, the UBNT client is out of my reach and I have no way to get it
Which makes me wonder, how comes that, the Mikrotik router does the NAT fine, and the pfSense not ?
I do not blame pfSense, just help me out with what to configure there...
that is what I'm after.
Factory defaulted Mikrotik with a single rule added works. No other specific config due to whatever the ISP might be doing. So if that router handles it well, I do expect the pfSense to do the same - but it seems it needs to be configured somehow more. Any ideas ?If I figure it out, I'll post it here.
I need to (and want to) get the pfSense to work in the very setup. - the initial issue - no NAT action for my setup - brought me so far
-
@icansoft said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
Which makes me wonder, how comes that, the Mikrotik router does the NAT fine, and the pfSense not ?
Now we're talking. Exactly!
Factory defaulted Mikrotik with a single rule added works. No other specific config due to whatever the ISP might be doing. So if that router handles it well, I do expect the pfSense to do the same - but it seems it needs to be configured somehow more. Any ideas ?
Somehow I smell "darkmagic(tm)". Almost sounds like some kind of upnp/natpnp at work that automagically requests the port upstream from the UBNT device, which in turn maps the port, which in turn leads to the package being delivered. As I don't play around with Mikrotik that much, I don't know if that's what they do per default, but that would be one guess (some kinda NAT punch technique).
Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!
If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.
-
@icansoft said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
Factory defaulted Mikrotik with a single rule added works.
None of us would be able to understand why this would be unless your ISP had done port forwarding to it's IP address.. which your pfsense box is obviously not obtaining. I.E. if your Microtik box got 192.168.1.60 and they set up a port forward to that box then your pfsense would also have to get .60 in order to receive that traffic. Since it does not we can only guess.
Triggering snowflakes one by one..
Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box. -
@JeGr said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
Almost sounds like some kind of upnp/natpnp at work that automagically requests the port upstream
^^ or that..
-
@chpalmer said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
@icansoft said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
Factory defaulted Mikrotik with a single rule added works.
None of us would be able to understand why this would be unless your ISP had done port forwarding to it's IP address.. which your pfsense box is obviously not obtaining. I.E. if your Microtik box got 192.168.1.60 and they set up a port forward to that box then your pfsense would also have to get .60 in order to receive that traffic. Since it does not we can only guess.
@chpalmer also has a good point. Does your mikrotik router get the same IP every time you plug it in behind the UBNT device? Does it also work every time? What if you shut it down and statically configure pfSense' WAN to the IP that the mikrotik had before?
@chpalmer said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
^^ or that..
that's what happens if we write at the same time, hehe
-
Somehow I smell "darkmagic(tm)". Almost sounds like some kind of upnp/natpnp at work that automagically requests the port upstream from the UBNT device, which in turn maps the port, which in turn leads to the package being delivered.
Right, right, I'm going to investigate. Not that I know Mikrotik any better to be able to answer this.
Anyway - have a look at the captured packet on top, it comes with the Source IP as original and unmodified, and target is the IP of the only device on the UBNT (ISP) subnet. If that is that Mikrotik (or my NB for that matter), the packet is captured... if it is pfSense, no luck.
The ISP has no idea what is on my network, and I've just verified it by changing MAC on the Mikrotik, it gets assignment from UBNT (different .ip) and yet it DST-NATs OK.
-
OK by thinking this through (and thank you all for helping me out to do so),
there definitelly must be some sort of detection mechanism on the ISP side.I think @chpalmer has the best answer, which makes the best of the sense, ... yet there must be something which I'm missing (and therefore it would be hard for others to figure it out as well).
I'll write an email with a query to the ISP, on how the configuration is done.
Perharps they somehow detect the device connected to a client of theirs, and it just happen that the pfSense is not handled properly on the ISP's side.
No idea if I ever get a response though.Anyway, I would consider the case closed. There is no more that could be done on the pfSense side.
Many thanks to all, you guys helped.
Please eventually move this thread to a more proper topic, if required. -
@icansoft said in pfSense NAT not working, nor showing related incoming packet in Packet Capture (even yet it is on wire) or in logs:
If that is that Mikrotik (or my NB for that matter), the packet is captured... if it is pfSense, no luck.
Yeah we get that. But even UBNT has no automagic guessing crystal ball as to automagically guess/read, what it will hand out your router as DHCP address and again automagically forward every packet to that address. Also: if you would attach that line from your UBNT to a switch and then to both the pfSense and mikrotik router, it would hand out two addresses as that's what DHCP does. So where should it route your packets to? That's why I'm guessing strange things happening like some UPnP/NATPnP magic.
Various home/SOHO routers like those AVM boxes have an option like "allow devices on the LAN to ask for port forwardings via UPnP". If something like this is working on the Mikrotik (as in you create a forwarding and it sends the request upstream), no wonder it "just works". But as my example above: what would happen if you'd attach multiple routers behind it? The box could never just assume "send anything to xy" with more then one DHCP client.
So either the Mikrotik is doing some UPnP (or other magic) that the UBNT box is allowing or it gets the same IP everytime and your ISP configured the box to always route it to e.g. IP .99 or anything the like.
I'd recommend using a static IP on the WAN side of your pfSense box anyway. I'd talk to the ISP if they could disable / rearrange the DHCP to exclude e.g. 192.168.1.2 or .1.254 from the DHCP segment and if they could please full-forward all traffic to said IP .2 or .254
So you don't have to guess what does what and simply know it will be sent there to which device whatsoever has it :)
-
Must be somewhere within these lines. There is simply no other answer.
Quite possible that the Mikrotik has set it up somehow, and it persisted for some time, but it got (who knows) cleared when switched to pfSense. Without additional info, it is now all just guessing.
I'll query the ISP on what are they doing there. Doubt they'll talk... but that is a different story.
I feel bad the pfSense was the one who got the blame, I have to apologize to it for that :) but the best apology is that I yet want to keep it and use it, it is a great thing, with a great support BTW.
But hey, without going this way, I would have not got this far. This whole discussion helped, a lot ! -
Oh, and I forgot to write down a "solution" that is right now working within my place, at the moment.
In case anyone else would face a similar issue (with a small rural european ISP... and a unknown uppath setup):Originally, I had the pfSense connected right to the ISP's POP; this did not go well for the NAT (even though it was finally not the issue of the pfSense's NAT itself, but an issue of the system setup including the pfSense);
now I have simply inserted a vanilla Mikrotik router in between (ISP and pfSense).
The router does src-nat and dst-nat, and the pfSense nicely humms right behind that, doing the firewall job as well as the NAT.
Of course this is not a clear way to do, nor a solution I'd ever like to keep, but it is a band-aid I have just needed.Thanks to all of you within this thread, your comments allowed me to figure this quick dirty fix up !
-
I'll query the ISP on what are they doing there. Doubt they'll talk... but that is a different story.
Just as a quick follow up: If you pay for your own public IP to get forwarded to you, they should have no trouble setting their UBNT POP the way you want. Otherwise what's the gain in paying for something you can't successfully use all the way you want? ;)
