Inconsisten NAT, tcpdump lunacy
-
My problem seems weirder than usual, not even sure if it belongs in this subforum. I'm trying to access security system dvr from internet. I have websever on port 8096, then it needs a tcp port on 37777 and I have 9600 forwarded to that, and it needs a udp port on 37778 and I have 9601 forwarded to that. See nat and rules below. And also the filter log, where it is seen that one gets through and the rest blocked. I don't know enough about how ports are handled to understand why the one that gets through is shown to have the correct destination, but the rest just show the firewall IP.
I tried to use packet capture to investigate, both promiscuous and not, no other stipulation, and it's only capturing traffic to and from the computer I'm communicating with pfsense with, a different machine, I don't have pfsense running on vbox or anything unusual like that???? Tried running tcpdump from ssh connection on the same computer, it did the same thing, tcpdump -i fxp0, no other stipulations. That is beyond me how/why that's happening. I tried http://www.canyouseeme.org/, Open Port Checker, it shows yes on 8096 and 9600, but no on 9601. Some of this likely due to the security cam software, but not the packet capture, and I need that to see what's going on.
Thanks for any help, I've only had to resort to coming here a few times and have always gotten generous support, this is a great forum.
-
It will immensely help if you start testing NAT from WAN and not from LAN, or fix your internal DNS to point to where things actually are.
-
It will immensely help if you start testing NAT from WAN and not from LAN, or fix your internal DNS to point to where things actually are.
I am. I don't understand the DNS thing. The 96.x.x.x is my IP address, the 162…. is the vpn my phone is connected through. Am I missing something? The NAT worked for one packet?? I guess, but then quit. That should mean it's set up correctly at least to some degree. The app on my phone comes up but only partially, I get logged in but the video feeds are broken. I assume they're coming in on the UDP port, but I'm not seeing anything passed or blocked. And there's still the tcpdump thing that makes no sense, you can see the connections in the firewall log, but they're not getting seen by packet capture.
-
Huh? What VPN?
-
I'm using a VPN to access my lan from outside. I could just use the phone off wifi but that uses a lot of bandwidth. I often use one on a PC to do the same thing. It's PrivateInternetAccess.
-
I don't get what you are doing there. If you are using site-to-site VPN, kindly use the internal IPs, not the WAN IP.
-
The vpn is irrelevant, it's only to get me outside my lan so I can test access. You can see it's clearly doing this from the logs, though not from tcpdump. I thought this was a rather normal thing, it's the way I've tested access to my local servers from the internet for years.
-
I think maybe there is confusion, when I say 'the app on my phone', I'm talking about the app I'm testing, it's the security system app for accessing the dvr from both lan and wan. I put in my internet link, which is a dynamic dns link, which is working. I've been doing this for years as I say. There islikely something weird with this app, but I can't really figure this out until I can look at the traffic coming in, which should be easy with packet capture, the one in pfsense web gui, but it's only capturing packets to or from the PC I'm using to access the web page. WHY? That is too weird, I even tried tcpdump run through ssh and putty on pfsense, with the command 'tcpdump -i fxpo', fxpo is the interface for the wan. And it too is only capturing packets to and from the computer I'm using to access pfsense. I keep thinking I must be making some simple, stupid mistake, but I can't see it.
-
The VPN is not irrelevant, what you are doing will NOT work unless you assign the OpenVPN interface. The traffic is routed, not NATed! You are simply testing things in completely wrong way.
-
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.
