LAN NAT redirect to another port doesn't work?
-
-
the traffic comes in on the WAN interface on port 15800 and 15900 (made it easier as range)
destination it 5800 to 5900
the rule say's it allows inbound traffic on WAN on the port's 5800 to 5900 but should on 15800 to 15900.i think this is more a gui problem since the rule actually work but display's the wrong numbers.
(had a friend access port 5900)
-
Rules are applied after NAT translation.
I am pretty sure that the way we do it is correct.
-
didnt know that rules are applied after translation.
then the rules make sense :)maybe there should be somewhere a note somewhere that NAT-translation happens before the firewallrules are applied..
because if you look at the rules and think they are applied on the interface on which the traffic comes in first thing it does not make sense. -
Rules are applied after NAT translation.
I am pretty sure that the way we do it is correct.
Correct, NAT (source or destination) occurs before all packet filtering (per interface). It can screw with your head, but I've learned to think of it as filtering what the traffic intent is, not what the ingress packet looks like on the wire.
–Bill
-
the traffic comes in on the WAN interface on port 15800 and 15900 (made it easier as range)
destination it 5800 to 5900
the rule say's it allows inbound traffic on WAN on the port's 5800 to 5900 but should on 15800 to 15900.i think this is more a gui problem since the rule actually work but display's the wrong numbers.
(had a friend access port 5900)The blocks here don't match your rules. You correctly have nat entries for port 15800 and 15900 redirecting to 5800 and 5900 respectively, and filter policy that correctly matches the destination host on port 5800/5900. Your block is from a different nat entry as it's directed to a completely different host 172.17.99.6 instead of 172.17.100.10.
–Bill
-
Sort of an indirect issue as a follow up. I've got my NAT and access rules in place and I can see the port status is open when I scan with nmap..
I have a similar setup - redirecting port 443 of a carp virtual IP to 8443 of an internal IP, the only difference in our setup are that I'm redirecting on incoming from wan2 (opt1) into the LAN and also have a general NAT rule to redirect LAN traffic out the WAN interface.
phew.
My problem is that while I can connect to 66.xxx.xxx.74:443 and watch it redirect to 192.xxx.xxx.20:8443 - I don't see any traffic leave 192.xxx.xxx.20:8443 destined for my client machine through the .74, or the default .82 address.
Now after digging regarding a different issue I come to discover that multi-wan w/ ftp on wan2 does not work period - is my current lack of traffic also caused by the same issue?
Any reply would be immensely helpful.
-
How does the nat entry look for wan #2 and the firewall rule entry?
Note: you do not set a gateway on this type of rule.
-
I won't actually go cutting and pasting, but if you can picture the table layout, the nat rule goes as follows:
(at the bottom of the portforward list)
WAN2 TCP 443 (HTTPS) 192.xxx.xxx.20 (ext:66.xxx.xxx.74) 8443Firewall rule looks like this from the WAN2 tab:
TCP * * 192.xxx.xxx.20 8443 *No gateway is set for the rule and I do seem to be able to telnet into 443 outside and arrive at 8443 inside and I also see from tcpdump on that server traffic going back out. I think something about the connection isn't working correctly since previously I could test my app against this same server, same port setup etc, but now i receive network connection errors..
I previously had this configured behind an OpenBSD box in almost the same manner so I don't think it's a pf issue since that was working before with an almost identical setup. I had 1 whole machine for each external subnet so each machine had just 1 ext and 1 int interface - now I'm just running each external subnet off it's own ethernet interface, with the 3rd reserved for LAN.
FYI The ext: address is actually the address of the WAN2 interface and not a virtual of any type, and yes I made sure to change the port webconfigurator runs on.. ;)
-
What version. Are you using Advanced Outbound NAT? If so are the entries defined for the wan #2?
-
Here's the relevant output of pfctl -sa | grep 443
These look pretty much identical to what I had before which is what makes me wonder what's changed other than OpenBSD vs pfSense
No advanced outbound nat, should I be?
I'm using the Hacom embedded image of 1.0.1 for an Openbrick-E w/ 512Meg CF–-
pfctl -sa | grep 443
rdr on rl2 inet proto tcp from any to 66.xxx.xxx.74 port = https -> 192.168.0.20 port 8443
pass in quick on rl2 reply-to (rl2 66.xxx.xxx.73) inet proto tcp from any to 192.xxx.xxx.20 port = 8443 keep state label "USER_RULE: NAT App Server port redirect"
If you want any other output let me know.. I could paste the /tmp/config.debug if it would help.
-
Please try upgrading to a later version.
-
I've got some pretty serious reservations about deploying a beta release to soon-to-be production equipment..
First I have to verify this isn't some issue with our app, however if it's not our app's problem then unfortunately I will be forced to look for a different platform until such time as a non-beta release can do the job.
Riddle me this.. Is it possible this is a result of using WAN2 and would I be better off having both sides of the T1 run into a switch and run both subnets from the single WAN interface?
This would free up the third interface for carp/failover communication and give me access to loadbalance/failover scenarios even though I am just pushing my point of failure down to the switch.
Sorry it's moving off topic..
I'll put up a bounty to have this fixed if indeed the problem does not lie in my application and is in fact a pfsense issue…
-
I have some serious reservations about folks running 1.0.1. 1.2 even in beta stage has thousands of fixes not included in 1.0.1.
It is by far more stable than 1.0.1 but its your equipment and it is your choice. Just be advised that most folks are running 1.2 happily these days.
-
I have some serious reservations about folks running 1.0.1. 1.2 even in beta stage has thousands of fixes not included in 1.0.1.
Right, but remember that it is still beta and some folks aren't keen on using that. The latest stable release for now is 1.0.1 so I would guess lots of folks (still) using it. However, this will change with the release of 1.2 stable.
The beginning of this thread showed that it would be helpful to have something like a 'big picture' of pfSense.
What, where and in which order would be great! Recently you suggested a nice Web drawing tool…
What do you think?Chris
