Inconsisten NAT, tcpdump lunacy
-
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.
