Inconsisten NAT, tcpdump lunacy
-
I don't understand what you are saying. What I've done clearly works, you can see it in the log, see my first post. I'm using an external vpn, privateinternetaccess, I don't have a vpn set up on my router.
-
It's clear from these log entries:
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:SThe IP address 162.216.46.126 is the IP of my phone through vpn, 10.0.0.106 is the LAN IP of the DVR I'm trying to talk to, 96.x.x.44 is my pfsense IP address on the wan side. Clearly, my phone is 'out there' on the internet and is trying to communicate with the DVR. The PC I'm communicating with pfsense is on 10.0.0.88, and that is the only LAN IP that will show up in packet captures.
-
Dude. You cannot meaningfully test NAT on WAN interface via OpenVPN. Period. End of story.
-
The previous replies got me wondering if I was having mental issues, I turned off the vpn and wifi on my phone and accessed the dvr through the cell network. Not much change. This is what shows up in the filter log:
Mar 9 01:06:33 WAN NAT forward for 16 ch-9600 (1465142205) 208.54.83.149:61652 10.0.0.106:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:38213 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:26041 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:42915 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53303 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:27877 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53869 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:40052 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:32487 96.x.x.44:37777 TCP:S Mar 9 01:06:35 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59887 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:32487 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:38213 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:26041 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:42915 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53303 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:27877 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53869 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59887 96.x.x.44:37777 TCP:S Mar 9 01:06:36 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:40052 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:26041 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:38213 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:42915 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:27877 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53303 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:53869 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:40052 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:32487 96.x.x.44:37777 TCP:S Mar 9 01:06:38 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59887 96.x.x.44:37777 TCP:S Mar 9 01:10:48 WAN NAT forward for 16 ch-9600 (1465142205) 208.54.83.149:18821 10.0.0.106:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41066 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57094 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:46943 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59916 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:25795 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:55453 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:29087 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57993 96.x.x.44:37777 TCP:S Mar 9 01:10:50 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:23543 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:23543 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41066 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:46943 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:25795 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57094 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57993 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:29087 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59916 96.x.x.44:37777 TCP:S Mar 9 01:10:51 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:55453 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41066 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:46943 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57094 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:25795 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:59916 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:57993 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:29087 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:23543 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41640 96.x.x.44:37777 TCP:S Mar 9 01:10:53 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:62885 96.x.x.44:37777 TCP:S Mar 9 01:10:54 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41640 96.x.x.44:37777 TCP:S Mar 9 01:10:54 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:62885 96.x.x.44:37777 TCP:S Mar 9 01:10:56 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:41640 96.x.x.44:37777 TCP:S Mar 9 01:10:56 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:62885 96.x.x.44:37777 TCP:S Mar 9 01:10:56 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:60959 96.x.x.44:37777 TCP:S Mar 9 01:10:57 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:60959 96.x.x.44:37777 TCP:S Mar 9 01:10:59 WAN Default deny rule IPv4 (1000000103) 208.54.83.149:60959 96.x.x.44:37777 TCP:SThere is a bit more info, there is a second packet that gets through. None of these got captured by packet capture through the web gui or by tcpdump run on pfsense directly by SSH login. One other difference in the packet capture was a scattering of packets not from or to the 10.0.0.88 address which is the computer I'm using. Including a few DNS queries from the DVR I'm trying to access on 10.0.0.106.
Isn't packet capture supposed to see these packets that are getting logged?
Why are only 2 out of all of these getting NATed? I don't know anything about how the ports are handled wrt to the ones used on the wan side vs the actual port that is specified, e.g. in the two that worked, we have ports 61652 and 18829 with actual destination 37777. I think it's some random assignment for security purposes but don't remember. I'd like to see what's going on in these packets, but since they're not captured, I can't.
The phone app for the security dvr system comes up, I get logged in, and the frames for the cameras come up, but then it can't get the video streams. I imagine the UDP port is for that, but there is no evidence there is any attempt for UDP getting used. It's not getting filtered, but whether there is any UDP traffic isn't clear because of how packet capture is behaving. And why isn't there any http traffic? I have to use the port in the URL address in the phone app, if I don't, it doesn't work at all, fails to connect. So, something has to be getting sent on port 8096, so why isn't it getting captured, and why isn't it logged? It is set to log the passes, but I don't see it, not in the numerous times I've tried.
Anyone have any ideas? I must be doing something stupid, but don't see what. Obviously, I'm no expert, not even close, but this seems like something that should be relatively straight forward and is something I've done for a long time. So I'm stuck, this appears anomalous to me.
-
Dude. You cannot meaningfully test NAT on WAN interface via OpenVPN. Period. End of story.
You can keep saying that, but that isn't how this works, you have to tell me how I'm wrong, you can't just say I'm wrong. You also have to explain how I've been doing testing of severs on my lan through a vpn, and have been doing so for years. AND, how do you explain that it does indeed work, as you can see in the log? Also, you have to expalin my last post which shows the same results with no vpn involved. AND PLUS etc, I don't know if I'm even using OpenVPN, is that what privateinternetaccess uses?
You can 'period. end of story' all you want, but you're not even close to addressing a single issue I've raised, and raised more than once, and shown the evidence that you don't seem to even try to look at. The story ain't over and I'm not on my period. Being male, that would really be anomalous.
-
You can keep saying that, but that isn't how this works, you have to tell me how I'm wrong, you can't just say I'm wrong.
You can read the book and/or read the free docs. I don't have time for arguing such nonsense. Bye.
-
You can keep saying that, but that isn't how this works, you have to tell me how I'm wrong, you can't just say I'm wrong.
You can read the book and/or read the free docs. I don't have time for arguing such nonsense. Bye.
You don;t have the time to look at the effing question apparently. Christ, when I've had to come here before, I got courteous folk who tried to help, and competently too. Why don't you try reading my posts? You haven't yet addressed a single thing, you just keep asserting nonsense, obvious nonsense to anyone who reads my original post. FFS, good bye, good riddance.
-
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.
