Inconsisten NAT, tcpdump lunacy
-
Dude, if you cannot understand that in order to test NAT on WAN you must access the thing from WAN (and NOT LAN, or OpenVPN, or IPsec), you can continue pulling your hair till there's some left. Perhaps get someone to configure the thing for you. Shockingly, it all works when tested with http://www.canyouseeme.org/ (and no, you cannot meaningfully test UDP ports like this, so there's actually zero problems with the entire thing, except for your PEBKAC.)
If you want to use OpenVPN to access the DVR, you point the OpenVPN client to to the LAN IP of the DVR. Not the WAN IP. You do NOT setup NAT for that.
Geeeeeez. ::) :o >:(
-
Dude, if you cannot understand that in order to test NAT on WAN you must access the thing from WAN (and NOT LAN, or OpenVPN, or IPsec), you can continue pulling your hair till there's some left. Perhaps get someone to configure the thing for you. Shockingly, it all works when tested with http://www.canyouseeme.org/ (and no, you cannot meaningfully test UDP ports like this, so there's actually zero problems with the entire thing, except for your PEBKAC.)
If you want to use OpenVPN to access the DVR, you point the OpenVPN client to to the LAN IP of the DVR. Not the WAN IP. You do NOT setup NAT for that.
Geeeeeez. ::) :o >:(
Oh FFS, what is your problem? I did access from the WAN but you refuse to look at the stuff I posted which shows this, you just spew your obviously intentionally ignorant, ahole BS at me over and over. You're assertions haven't changed, my first post is clearly all the evidence any half-assed intelligent person would need to see that you are full of shit. That I keep telling you to look at the data I posted, and you refuse, is telling. This is pathetic, aren't there any grownups here anymore? Do you even know how to read?
-
"then it needs a tcp port on 37777 and I have 9600 forwarded to that"
So your trying to forward traffic that hit on port 9600 of your wan address to 37777 to your webserver. But your firewall hits are all to port 37777, well yeah there is nothing in your rules that would allow that traffic.. If you want to get to 37777 on your webserver via 9600 then you need to hit port 9600 on your wan address.
-
Thanks for the reply, an informed one too ;D, it's appreciated. It's a little more complicated than that. The dvr with the server is set to listen for http traffic on 8096, but it also wants a tcp connection on port 37777, that's its default, and UDP on 37778, also default, don't have a clue what data the ports carry, don't need to know, externally I'm using 9600/01 NATed to 37777/8. I believe my nat/rules do this. Am I missing something? As I said earlier, I've done this for years in other circumstances and it's worked just fine.
The real problems and what's really bizarre is the filter log showing the one pass and a bunch of rejects, all to 37777, with no hits, pass or block, for the 8096 html traffic, and no UDP on 37778. And the even more bizarre failure to capture any of this traffic with packet capture on the pfsense webgui, or with tcpdump run with SSH. Am I missing something? Shouldn't these be picked up with packet capturing/tcpdump? I've tried about 10 runs, all the same, they aren't seeing these packets, nothing but a few DNS queries in the logs for that address. Why is it passing the occasional 37777-bound packets and blocking the rest, while indicating the wrong destination? You can see that with the filter log entries, repeated here"
Mar 8 18:42:10 WAN NAT forward for 16 ch-9600 (1465142205) 162.216.46.126:40707 10.0.0.106:37777 TCP:S
Mar 8 18:42:12 WAN Default deny rule IPv4 (1000000103) 162.216.46.126:49951 96.x.x.44:37777 TCP:S
Mar 8 18:42:12 WAN Default deny rule IPv4 (1000000103) 162.216.46.126:49952 96.x.x.44:37777 TCP:S
Mar 8 18:42:12 WAN Default deny rule IPv4 (1000000103) 162.216.46.126:49953 96.x.x.44:37777 TCP:S
Mar 8 18:42:12 WAN Default deny rule IPv4 (1000000103) 162.216.46.126:49954 96.x.x.44:37777 TCP:S
Mar 8 18:42:12 WAN Default deny rule IPv4 (1000000103) 162.216.46.126:49955 96.x.x.44:37777 TCP:SI appreciate your efforts, especially since you looked at the data before coming to conclusions.
-
"externally I'm using 9600/01 NATed to 37777/8. I"
What does /01 and /8 mean??
That fine if you want to forward port X to Y… But for that to work you have to actually hit X..
And that is being allowed. Since it sees the dest port and you seem to have Any for your dest in your firewall wan rules. But your wan rule for your forward is set to only allow traffic that hits X and forward it to Y. Your hitting Y so yeah its blocked.
Post up your full wan rules and your port forward so can see if any other rules, etc.
But your firewall rules are wrong anyway - the dest should be your wan address.. See example mine attached..
-
"externally I'm using 9600/01 NATed to 37777/8. I"
What does /01 and /8 mean??
That fine if you want to forward port X to Y… But for that to work you have to actually hit X..
Your logging your port forward.. Yes the nat/port forward rules are evaluated first.. And that is being allowed. Since it sees the dest port. But your wan rule is set to only allow traffic that hits X and forward it to Y. Your hitting Y so yeah its blocked.
Not sure what tcpdump has to do with just logging yoru nat rules. Turn off logging your port forward and now you wont see that. Its not getting in because your not hitting the correct port!
9600 is ported to 37777 and 9601 is ported to 37778.
What does it mean 'I am hitting y'? If the port forward is working, isn't anything that comes in from the internet to pfsense on port 9600 supposed to get ported to 37777 on the internal host I set it too, 10.0.0.106, as shown in the nat/ruies figure in first post. The log shows packets coming in with a 37777 port destination, the first one gets properly routed, then the rest are blocked, showing what seems to be an UN-forwarded port 37777, so it shows the pfsense IP as destination. I'm supposing 'X' is the machine with pfsense, so anything coming in from the internet [wan] should get forwarded to 10.0.0.106, so I am supposing that is 'Y'. Is that right? If so, how are the blocked packets 'hitting Y'?
If a packet comes in and is logged, shouldn't it get captured by tcpdump? I need to see if there is something weird about the packets that are not getting forwarded, I need packet capture to do that. Is there some other way?
I want to see the port forwards so I can see what's going on, that's why I'm logging the passes. What tcpdump has to do with logging is that it isn't capturing these logged packets. Isn't that anomalous? Is there some switch I missed somewhere that would cause that to happen
How am I 'not hitting the correct port'? The blocked and the unblocked are all 37777, again, this is easily seen in the log.In the app on my phone that I am trying to get to work, I put in the address: myurl.com:8096. If I don't put the port in the address, the app times out, with the port, it comes up partially. So, I would think that means that at least something is coming in on 8096 and getting forwarded to 10.0.0.106, but this isn't in the log, which it should be, I set it to log passes, or the tcpdump. Again, isn't this anomalous? Seems seriously amiss to me, but then I'm no expert.
Thanks again for your efforts.
-
"What does it mean 'I am hitting y'? "
X=9600
Y=37777Your firewall rule allows traffic it Sees on X (9600).. This well then be forwarded to 37777 (Y)
Your log is showing that traffic is hitting Y 37777 so NO that would not be allowed..
Not sure what your talking about tcpdump - you have not posted any of that.
Why do you not just sniff on wan for port 9600, go to canyouseeme.org and put in port 9600.. Do you see this traffic. Via a sniff you will see it hit 9600, and if you sniff on your lan you will see that be forwarded to your 10. address on port 37777
Here I created the same sort of rule.. But forwarded it to 80, since I don't have anything listening on 3777..
So Last is your X is 9600, but your not hitting 9600 your hitting 37777 in your logs.
So then see my forward and firewall rules and then me testing it.. I am using 80 vs your 37777 port.
See when I hit Y (80) its blocked.
Then I hit X (9600) and its forwarded but show in firewall log that I went to 80 on my rfc1918 address.
And then last you can see actual sniff.. So on wan I am hitting 9600.. But on the lan interface you see the traffic going to 80
-
If you look at my filter log, you can see that I have 9600 forwarded correctly, it is passed, once, then subsequent attempts get blocked. As far as I know, the app I'm testing is never trying to use 37777, I changed it, and it obviously tries at least once to come in on 9600 which is forwarded correctly. It sure as hell would be screwing up if, after one packet got through with 9600 for the port, it then started using 37777.
I already used canyouseeme, it says so in the OP– 8096 and 9600 are open, but not 9601. If you look at the OP, the NAT/rules are the same except for the numbers, they should act the same, shouldn't they? If the app is actually trying to go to 37777, that is what I need to find out, and I can't because tcpdump isn't catching it. I could post reams of tcpdump data, but that won't mean anything, it doesn't see any of this. THAT is the real problem, i should have just asked about the packet capture issue. I can't really know what is hitting pfsense without it.
I really appreciate your efforts. Please don't take offense, I think you and the other guy keep thinking I've made a stupid mistake, and maybe I have, but it's not that stupid, if you look at the stuff I posted in the OP, all of the info is there, you can see my NAT and rules, you can see the filter log. I just didn't post any tcpdump data because there's nothing to see, it's ignoring all of these packets for some reason, and that is the real issue.
-
All I see dude is firewall blocking traffic to 37777 which it should.
If your saying your hitting 9600 and its not being forwarded then show that with a tcpdump. All your showing is exactly what should happen.
Maybe your app is stupid and trying 37777.. At a loss to why you don't just forward that port if that is the port it uses vs changing them.
-
All I see dude is firewall blocking traffic to 37777 which it should.
If your saying your hitting 9600 and its not being forwarded then show that with a tcpdump. All your showing is exactly what should happen.
Maybe your app is stupid and trying 37777.. At a loss to why you don't just forward that port if that is the port it uses vs changing them.
You can see that 9600 is getting forwarded, it's in the filter log, see below, the first entry is a successful transfer to my lan address 10.0.0.106, along with the NAT/Rules info. You're telling me to show you something from tcpdump, but that's what no one wants to hear, it isn't catching any of the traffic on any of the ports, 9600, 9601, or 8096, nothing.. Neither tcpdump, nor packet capture from the webgui. In 10 attempts or so. As I said, you can see the packets in the log, but tcpdump isn't grabbing them. And that is the real problem,. like I've said in almost every post,. I can't really troubleshoot adequately if I can't see what's going on in the packets.
I don't want to just pass the traffic with the default port, both for security issues and because I have other devices that use the same ports. I might resort to that, as a test. But I really want to capture the traffic and can't understand why it's not getting captured.
-
Right. Followed by a bunch of SYNs to your WAN Address:37777 which is NOT forwarded and is PROPERLY being blocked.
pfSense is not making those connections. 162.216.46.126 is.
Almost like the initial connection results in that server telling the clients to connect back on 37777 which, as configured, will NOT work, as you can plainly see.
Just a guess since we know nothing of the protocol/service in play.
-
Right. Followed by a bunch of SYNs to your WAN Address:37777 which is NOT forwarded and is PROPERLY being blocked.
pfSense is not making those connections. 162.216.46.126 is.
Almost like the initial connection results in that server telling the clients to connect back on 37777 which, as configured, will NOT work, as you can plainly see.
Just a guess since we know nothing of the protocol/service in play.
Thank you for replying. I understand about where the connection is coming from, but how can you tell they are SYNs? And of course, the bigger question, is there any reason you can think of why packet capture/tcpdump is consistently ignoring/missing the packets involved? I've run it on the wan and the lan simultaneously, and it isn't seeing any packets from the addresses/ports involved.
And there is another issue, canyouseeme reports 8096, and 9600 as open, but 9601 as closed. The nat&rules look identical of course, except the numbers and protocol. Why this inconsistency, is the UDP protocol for 9601 an issue?
-
You keep saying packet capture/tcpdump - yet have not shown this…
How do you tell they are SYN... The big freaking S in the log ;)
The firewall is doing exactly what its suppose to do - block stuff that is not forwarded. 37777 is not forwarded. 9600 is is - so if you hit it on 37777 yes it will be blocked!! Your first log entry shows that port 9600 was hit and forwarded.. All those others are SYN to 37777 which are blocked by your current rules.
-
There's a couple of things I am going to try, figure out how to do packet capture on my phone and on my internal wifi router. I'm sure it's doable, but may take a while because it's a bit beyond my usual abilities, plus, it's probably going to be the end of what little hair I still have left. That should at least tell me what the app is trying to do. I should also set the app back to its default and change the nat accordingly and see what happens.
-
figure out how to do packet capture on my phone and on my internal wifi router.
ROFL. It's still going on? Don't use your internal wifi for testing WAN. Why'd you be doing a packet capture there? Why would it be routing things from WAN?
-
You keep saying packet capture/tcpdump - yet have not shown this…
How do you tell they are SYN... The big freaking S in the log ;)
The firewall is doing exactly what its suppose to do - block stuff that is not forwarded. 37777 is not forwarded. 9600 is is - so if you hit it on 37777 yes it will be blocked!! Your first log entry shows that port 9600 was hit and forwarded.. All those others are SYN to 37777 which are blocked by your current rules.
OK, this is exposing how far I'm not an expert, I didn't know what that 'S' meant. I'm not a complete idiot, but not that far off. That means the app is not behaving as it should be, and I'll have to deal with their tech support. I'd still really like to know why packet capture seems to perversely ignore exactly the packets I'm interested in. Will try what I posted ^^. Thanks again, and sorry for the ignorant question, I used to enjoy these things a lot more, good learning experiences, fun puzzle, don't know if it's the age thing or that there's too much other BS going on at the moment that I don't have the time.
-
"I'd still really like to know why packet capture seems to perversely ignore exactly the packets I'm interested in. "
Have not idea since you have not posted any sort of packet capture showing anything.. If you where for example trying to capture on your wan for 9600 and your application is sending 37777 then no you wouldn't see anything..
Why don't you show your sniffs from your send and recv side and then point out what you think is missing.. Are you trying to say your sniffing on wan and not seeing these syn packets to 37777 that firewall is logging in its block?
-
figure out how to do packet capture on my phone and on my internal wifi router.
ROFL. It's still going on? Don't use your internal wifi for testing WAN. Why'd you be doing a packet capture there? Why would it be routing things from WAN?
I'm not doing that. I use my phone hooked up through an external VPN, privateinternetaccess. The first guy to reply to this thread could not get it out of his head that this is a good way to test your system, I'm pretty sure he could not accept that it was an external, non-pfsense VPN, so he thought I was using a VPN run on pfsense. At least I think that's what he thought. Who knows? Anyway, I've tested my local servers this way for years.
My phone is connected to my wifi router, which has all routing/dhcp/etc cut off, so if I try the app, then the packets would have to go out through the router, to the vpn, then back to pfsense. Unless I'm missing something basic, I should be able to capture the packets as they pass through the router. I realize I'm kinda above my pay grade here, please tell me if there is something stupid I'm trying to do???
-
The first guy to reply to this thread could not get it out of his head that this is a good way to test your system. My phone is connected to my wifi router, which has all routing/dhcp/etc cut off, so if I try the app, then the packets would have to go out through the router, to the vpn, then back to pfsense.
Yeah, that guy was me. And it's amazing you are STILL "testing" things in this super-broken way. Take the damn phone to the nearest cafe with WiFi.
-
"I'd still really like to know why packet capture seems to perversely ignore exactly the packets I'm interested in. "
Have not idea since you have not posted any sort of packet capture showing anything.. If you where for example trying to capture on your wan for 9600 and your application is sending 37777 then no you wouldn't see anything..
Why don't you show your sniffs from your send and recv side and then point out what you think is missing.. Are you trying to say your sniffing on wan and not seeing these syn packets to 37777 that firewall is logging in its block?
I haven't posted the tcpedump data because there isn't any, nothing involving the address and ports from the outside IP, nothing on the ports involved, zilch–I can't point to what's missing, how does one do that?. I've done this upwards of 10 times, I've done tcpdump with this command 'tcpdump -i fxp0', that isn't restricting the capture in any way other than restricting to the wan. I've also done packet capture from the web gui, including both the lan and the wan, and get the same result, which is zilch. This is weird, this is anomalous, this is what I've said from the OP that I think is the bigger issue. Am I missing something obvious?
