Inconsisten NAT, tcpdump lunacy
-
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?
-
"then the packets would have to go out through the router, to the vpn, then back to pfsense. Unless I'm missing something "
Well clearly from your log the app gets through when it tries 9600.. What the app does then, and how your testing is setup could be why your seeing weirdness.
Maybe the app gets told use 37777 vs 9600.
If you want to test from your phone - I would not suggest a vpn connection over your wifi to some external vpn service.. Why not just use your cell data connection.. Or if you really want to use a wifi connection use the wifi next door..
Have no idea if your split tunnel on that vpn connection? And your also trying to nat reflect, etc.
It is always best when testing to actually be outside!!! not some crazy hairpin from in to out and then back to your public just to go back in to some server next to you on the same network.. Be it you force that client outside with a vpn or not..
Also why don't you test using the actual ports.. 37777 is normally some video nvr/dvr port.. Is that what your trying to access from the outside???
Dude - here is some advice.. Don't do that!!! If your outside and want to check your video connections - then VPN into pfsense from the outside!!! This is way more secure than trying to just hide the port your using by changing it to 9600, etc..
And also a 30 second setup - run through the openvpn wizard. Install the openvpn client on your device.. Use the config - bing bang zoom your watching your video of your house while your at starbucks in full secure fashion - with no worries of anyone else finding your video stream or hacking your video device, etc.. Did you not just read the listing of some 2500 ip camera's that pretty much have zero security for someone to add them to their bot net ;)
-
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.
If I did that, I would still hook up to the same VPN, how would that be different? If it shouldn't be working, why does it? As I said repeatedly, you can see in the firewall log that it works, and as I've said repeatedly, I've tested local servers like this for years. What is amazing is you refuse to answer a single question I ask that would clarify this misunderstanding, you only keep telling me it doesn't work. Hint–if it is working, telling me it can't work looks kinda silly.
-
dude see my edit.. You really should not be opening up your camera/video streams to the public.. That is what your trying to do right with that 37777 ports.. That is normally video stuff.
-
"then the packets would have to go out through the router, to the vpn, then back to pfsense. Unless I'm missing something "
Well clearly from your log the app gets through when it tries 9600.. What the app does then, and how your testing is setup could be why your seeing weirdness.
Maybe the app gets told use 37777 vs 9600.
If you want to test from your phone - I would not suggest a vpn connection over your wifi to some external vpn service.. Why not just use your cell data connection.. Or if you really want to use a wifi connection use the wifi next door..
Have no idea if your split tunnel on that vpn connection? And your also trying to nat reflect, etc.
It is always best when testing to actually be outside!!! not some crazy hairpin from in to out and then back to your public just to go back in to some server next to you on the same network.. Be it you force that client outside with a vpn or not..
Also why don't you test using the actual ports.. 37777 is normally some video nvr/dvr port.. Is that what your trying to access from the outside???
Dude - here is some advice.. Don't do that!!! If your outside and want to check your video connections - then VPN into pfsense from the outside!!! This is way more secure than trying to just hide the port your using by changing it to 9600, etc..
And also a 30 second setup - run through the openvpn wizard. Install the openvpn client on your device.. Use the config - bing bang zoom your watching your video of your house while your at starbucks in full secure fashion - with no worries of anyone else finding your video stream or hacking your video device, etc.. Did you not just read the listing of some 2500 ip camera's that pretty much have zero security for someone to add them to their bot net ;)
Your right on all of that, it's something I've planned to do, but as can be seen here, I can't even get the thing to run without the added complexity of setting up and connecting through a VPN on pfsense. But yeah, it's time to really tighten up security as much as is possible.
The reason I need to change the ports is that I have multiple devices that all default to the 37777/8 ports. And way back on reply #12, I turned off the VPN and went through the cellular network and everything was the same.
Split tunnel and nat reflect, don't have either set up, turned on, whatever. What I'm doing is much simpler, just using an external vpn to get me outside on the wan, I know this works, I've done it for years, and it's really basic and simple, which is good because I'm basically simple.
-
What is amazing is you refuse to answer a single question I ask that would clarify this misunderstanding, you only keep telling me it doesn't work. Hint–if it is working, telling me it can't work looks kinda silly.
It apparently is NOT working. Point completely moot. What else you have there to rebut the statement that your testing methodology is just braindead and hopelessly broken?
-
dude see my edit.. You really should not be opening up your camera/video streams to the public.. That is what your trying to do right with that 37777 ports.. That is normally video stuff.
I agree and am going to go that route, see prior response. And thanks, I appreciate the info and concern.
-
What is amazing is you refuse to answer a single question I ask that would clarify this misunderstanding, you only keep telling me it doesn't work. Hint–if it is working, telling me it can't work looks kinda silly.
It apparently is NOT working. Point completely moot. What else you have there to rebut the statement that your testing methodology is just braindead and hopelessly broken?
More assertion As I've said repeatedly, the first log entry shows it works, period. As I've said, repeatedly, I've done this for years. Maybe if you could explain why it shouldn't work? The other responder has no problem seeing that it works, what is it you're missing?