Inconsisten NAT, tcpdump lunacy
-
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.)
-
dok I am with you its a F'd up way of testing.. But he is running a vpn on the client pointing default out the vpn tunnel. So while yes its a hairpin of a mess - it can be used for testing from the outside. Not sure why you wouldn't just test from outside directly… But his mess can work.. In this case clearly there is something else going on - ie what it looks like to me is his app is changing to using the 37777 port vs the 9600 port he is telling the app client to use..
So you have attached.. Which yes is a mess ;)
"(Not really sure what wizard are we talking about now, at all.)"
The openvpn wizard in pfsense..
-
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.
But it does work, if you insist that it doesn't, how do you explain the first filter log entry? This is only about the 6th time I've asked this, why can't you address this and maybe we wouldn't be wasting this space? I don't get the rest of what you're saying at all. As I pointed out in post #12, I turned off the VPN, and connected through my phone with wifi turned off, and everything behaved exactly the same. I can use the vpn either through my lan via wifi, or through the phone network with wifi turned off, and the results are the same. Why is this overly complicated? How is it any more complicated than going to a wifi cafe and using the vpn through their network?
As to using a my own vpn set up on pfsense, I'm doing that now.
-
dok I am with you its a F'd up way of testing.. But he is running a vpn on the client pointing default out the vpn tunnel. So while yes its a hairpin of a mess - it can be used for testing from the outside. Not sure why you wouldn't just test from outside directly… But his mess can work.. In this case clearly there is something else going on - ie what it looks like to me is his app is changing to using the 37777 port vs the 9600 port he is telling the app client to use..
So you have attached.. Which yes is a mess ;)
I have no doubt dok is far more knowledgeable than me, so I don't know how to handle his refusal to look at the data and explain how it's not saying what I think it's saying. Oh well.
I asked this of dok just now, but this is also a good place to ask the same question. How is my connecting through my subscription, outside-not something set up on pfsense, VPN privateinternetaccess, from my lan any more complex or weird than going to a local wifi cafe and doing it from there? The way I think of how vpn's work, is that as far as any of the machines involved can tell, the client device is sitting at the IP of the VPN and connecting like any other machine connected to the internet from that IP, the connection from the device to the vpn can be considered transparent, or as if it isn't there. I don't know the terms to use, but hopefully you can see what I'm trying to get across. Is this wrong?
In other words, using privateinternetaccess on my phone, connected through my lan or through the cellular network internet connection, compared to going to a wifi cafe and connecting through privateinternetaccess, where and what is the weirdness and complexity? Don't both of them make my phone appear as if it's got an IP that is the one provided by privateinternetacess, and is connected to the internet normally from that IP address? Is it really much different if the lan is my own or some wifi cafe's? I'm very open to finding out I'm full of crap, always ready to learn better.
-
Using the VPN just adds unneeded complexity when trying to troubleshoot.
For the analogy, you are trying to drive the car off the lot when you are still in the process of building the engine.
In terms of troubleshooting, it's usually best to reduce as many of the unknowns as possible to try to get it working and then build upon it.
You are looping back out and then back in so that just adds confusion to try to tcpdump/sniff the traffic coming out and going back in.
Rather than trying to figure out if the App is changing ports and what needs to be mapped, using the VPN on pfSense is definitely an easier approach and more secure.
-
Connecting directly to PIA using OpenVPN client on an inside device with redirect gateway set should be able to test that. Cell data is generally a better way to test from the outside.
It has been pointed out countless times that your device is connecting to WAN:37777 not WAN:9600 as you think it should.
Also:
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?
There is no reliable way to test a UDP port using something like canuseeme. It is not TCP. Forward the port and be sure the firewall rule is there. It will work. It always works.
-
Using the VPN just adds unneeded complexity when trying to troubleshoot.
For the analogy, you are trying to drive the car off the lot when you are still in the process of building the engine.
In terms of troubleshooting, it's usually best to reduce as many of the unknowns as possible to try to get it working and then build upon it.
You are looping back out and then back in so that just adds confusion to try to tcpdump/sniff the traffic coming out and going back in.
Rather than trying to figure out if the App is changing ports and what needs to be mapped, using the VPN on pfSense is definitely an easier approach and more secure.
Thanks. It was something I've done for a long time, before I even started using pfsense, but I've taken everyone's advice and set up openvpn sever and amazingly enough got it working before I needed to kill myself, if only barely. I think a better analogy would be driving off the lot while the salesman was standing in front of the car, just a minor bump inn the road.
-
Connecting directly to PIA using OpenVPN client on an inside device with redirect gateway set should be able to test that. Cell data is generally a better way to test from the outside.
It has been pointed out countless times that your device is connecting to WAN:37777 not WAN:9600 as you think it should.
Also:
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?
There is no reliable way to test a UDP port using something like canuseeme. It is not TCP. Forward the port and be sure the firewall rule is there. It will work. It always works.
Thanks, I didn't understand about canyouseeme and UDP, good to know. I did understand about the 37777 thing, but the tcpdump problem was screwing me, preventing looking at what it was doing.
It's now not a problem, as I said in previous post, I finally did what everyone's been telling me to do, and what I knew I should do, and set up openvpn server on pfsense and actually got it working.
-
OK, thank you all for helping me out, and especially for goading me into finally setting up the openvpn server. Particularly johnpoz, goader-in-chief, it wasn't as bad as I feared, I managed to stop the bleeding from my ears fairly quickly and got it running without too many problems. And even doktornotor, thanks for trying even if we didn't quite communicate adequately, I apologize if I got I got a bit too irked.