NAT passing through pf (says log) but not working….
-
Hi All,
My firewall log tells me that both a 1:1 nat to a camera server, and a port forward nat to a mail server are passing when I attempt connections to their different fixed IP's from outside.
For the cam server…
The rule that triggered this action is:
@92(1463011324) pass in log quick on pppoe0 reply-to (pppoe0 10.8.14.1) inet proto tcp from any to 192.168.1.100 flags S/SA keep state label "USER_RULE: Camera System"
But there is no connection...
Both work as expected from any LAN machine, no client firewalls etc.
Virtual IP's are correct.
I cant see any evidence of a connection attempt when looking at client machines live / or in logs...
pf Packet Capture shows:
xxx.xxx.163.158.5096 > xxx.xxx.176.162.80: Flags S, cksum 0x8f60 (correct), seq 2443826751, win 65535, options [mss 1452,nop,wscale 5,nop,nop,TS val 846387665 ecr 0,sackOK,eol], length 0
Firewall rules on WAN:
Protocol Source Port Dest Port G/W
IPv4* * * 192.168.1.100 * *Rules on LAN: default to ANY
States table shows:
WAN tcp xxx.xxx.163.158:9740 -> 192.168.1.100:80 (xxx.xxx.176.162:80) CLOSED:SYN_SENT 4 / 0 256 B / 0 B
Any clues? The Closed seems to suggest no response - but there is when on LAN…..
Cheers,
Phil
-
Judging by the state table, the firewall is passing it through but the local system is rejecting it. Check for local filters on the camera server and mail server.
And reconsider using any of that for a camera server. Never expose such things to the Internet in general. Use a VPN. They have notoriously awful IP stacks and security. Nobody should be able to even reach them but you, as they could have an exploit that works even without a user being logged in.
-
That was the conclusion I reached - and I am still trying to work out where the block is on the server.
Thanks for the advice about the cam, we plan to move it to an isolated LAN on a spare DSL.
All the best,
Phil.
-
I wouldn't trust that no matter where it is. Unless you want random people hacking in and watching your cameras. VPN is the only acceptable way to access such things remotely.
-
If your NAT rules are logging, try doing a tcpdump on the internal interface, and filter by the destination host and port. If youre not seeing traffic, you might want to check your firewall rules and ensure there are rules to allow it to pass. PFSense NATs before it filters (however I'm unsure if its able to ascertain you MEANT to allow traffic to an internal host based off of a port forward lookup.), so remember to make the statement on the WAN side to allow traffic to the internal IP of the destination, and not the WAN address of the firewall.
