Inconsisten NAT, tcpdump lunacy
-
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?
-
If you have multiple devices using 37777 then vpn also solves that problem since you just hit your different rfc1918 address of those devices.
While I do agree with dok on the testing method is not really a good one, I will agree that in theory it can work.. But when there is a problem like your having it does complex it up a bit. Especially if you can not get sniffs and that is normally hard inside an encrypted vpn tunnel ;)
You also have a added issue here is not understanding the actual protocol in use. For all you know that first connection is working and the app is switching to 37777 which is what your firewall logs are showing.
A vpn setup is really like 30 seconds. Install the export package so its easy to get the config for different clients. ios, android both supported with the openvpn app which is free from openvpn in and the respective stores. Bump through the bouncing ball in the wizard, export your config - bing bang zoom watching your video streams while at the local pub either on their wifi or your cell connection.. All secure!!
-
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?
How on earth it works when it clearly doesn't? If it worked we would not have this time-wasting thread here, would we?
Any why should it ever work? Why'd traffic to a local network normally go out via WAN/VPN, and why'd some reply to the traffic coming from local network to local network normally go back via WAN to get back via the same WAN and only then go to the client on the local network? You really cannot see what kind of absolutely unneeded complexity and how many totally pointless pitfalls are you introducing to something that's supposed to be a goddamn simple NAT (which works for everyone out of the box, click click done)!?
Plus, as endlessly repeated, you should use a VPN to access the video stuff directly from remote. You don't expose this DVR crap that has tons of backdoors and unfixable security bugs on Internet via NAT.
-
If you have multiple devices using 37777 then vpn also solves that problem since you just hit your different rfc1918 address of those devices.
While I do agree with dok on the testing method is not really a good one, I will agree that in theory it can work.. But when there is a problem like your having it does complex it up a bit. Especially if you can not get sniffs and that is normally hard inside an encrypted vpn tunnel ;)
You also have a added issue here is not understanding the actual protocol in use. For all you know that first connection is working and the app is switching to 37777 which is what your firewall logs are showing.
A vpn setup is really like 30 seconds. Install the export package so its easy to get the config for different clients. ios, android both supported with the openvpn app which is free from openvpn in and the respective stores. Bump through the bouncing ball in the wizard, export your config - bing bang zoom watching your video streams while at the local pub either on their wifi or your cell connection.. All secure!!
I'm going through the setup wizard right now, '30 seconds' and 'zoom', we'll see, my greatest expertise is in how facilely i can fubar just about anything.
As to how I'm testing, the objection about encrypted packets, isn't that only true on the outbound leg? Once through the VPN, everything is as if I was coming from the VPN IP normally, isn't it? This really is something I've done for years. Am I missing something?
-
You know, even if you make this work, the only thing you'll have tested by that time is that you make packets travel 4 times around the planet for no good reason. Not that the NAT works on WAN.
(Not really sure what wizard are we talking about now, at all.)
