"Inbound hairpin" routing?
-
Not sure what to call this; I can get it working easily enough on CLI, but would like a way to do it on the GUI.
Our pfSense has two WAN connections; one with a public IP and one that's stuck on a private network we don't control. For monitoring purposes, we'd like to make sure the equipment on the private network is up and running, from a remote site:
XXXXXX XXXXXX XXXXXXX +------------+ XXX XX | | X 9.8.7.6 XXXX | 10.0.0.104 | XXX XXX | | XXX XXXXXXX +------^-----+ XXXXX | 80 + | | | | 14800 +------+-----------------v--+ | 10.0.0.103 1.2.3.4 | | WAN2 (igb3) WAN1 (igb1) | | | | 192.168.1.1 | | LAN (igb2) | +---------------------------+I tried doing this in NAT rules, using the "NAT + Proxy" setting but it is hard-coded to doing the proxy bit on the LAN side. So trying to forward port 14800 to the internal equipment, I get these rules added:
rdr on igb1 proto tcp from any to 1.2.3.4 port 14800 -> 10.0.0.104 port 80 # Reflection redirects rdr on { igb2 igb2_vlan100 igb2_vlan900 } proto tcp from any to 1.2.3.4 port 14800 tag PFREFLECT -> 127.0.0.1 port 19000The redirection on igb1 takes the traffic and tries a straight NAT, which won't work of course. I can edit rules.debug to look like this and it does work:
rdr on { igb1 } proto tcp from any to 67.201.176.21 port 14800 tag PFREFLECT -> 127.0.0.1 port 19000Is there any way to do this in the GUI or am I stuck installing Squid? (Or, is there a way to pre-process the pf rules before reload?)
-
Are you limited to ICMP for monitoring or can you connect to an arbitrary TCP port on 10.0.0.104 to get status?
-
Are you limited to ICMP for monitoring or can you connect to an arbitrary TCP port on 10.0.0.104 to get status?
TCP monitoring the web interface. Can't imagine ICMP NAT could possibly work!
-
It works when you ping out to the internet.
Anyway.
If you port forward an arbitrary TCP port on WAN1 address to 10.0.0.104:80 and make sure that Advanced Outbound NAT is translating traffic from 9.8.7.6 (or whatever the source address of the traffic is) going out interface WAN2 to 10.0.0.103 it seems like it should work.
I don't see any need to muck about with reflection.
-
If you port forward an arbitrary TCP port on WAN1 address to 10.0.0.104:80 and make sure that Advanced Outbound NAT is translating traffic from 9.8.7.6 (or whatever the source address of the traffic is) out interface WAN2 to 10.0.0.103 it seems like it should work.
Yep, sounds like that's the ticket. You don't want or need reflection, the only reason that works is because it changes the source IP. Just source NAT is a much better way to accomplish that.
-
It works when you ping out to the internet.
Anyway.
If you port forward an arbitrary TCP port on WAN1 address to 10.0.0.104:80 and make sure that Advanced Outbound NAT is translating traffic from 9.8.7.6 (or whatever the source address of the traffic is) going out interface WAN2 to 10.0.0.103 it seems like it should work.
I don't see any need to muck about with reflection.
Of course, outbound NAT was the piece I was missing; it will change the source address just like the nc proxy was. Thanks a lot!
-
Yeah. I think about it like this:
Port forwards translate destination addresses and ports as connections come into an interface.
Outbound NAT translates source addresses and ports as connections go out of an interface.You usually only use one or the other but you can do both.
