Solved Hairpin NAT with IPFW - How to configure

W

willyvmm

I would like to configure a Hairpin NAT within my network.
An axample diangram below (image from https://support.netstream.cloud/knowledge/hairpin-nat ip's in my network are different, but idea is identical)

hairpin.png


my current ipfw.rules are:
sh: 
#!/bin/sh


ipfw -q -f flush

cmd="ipfw -q add"

WAN=vlan101

PROXY=10.0.0.3

ipfw disable one_pass

ipfw -q nat 1 config if $WAN same_ports reset unreg_only\
                redirect_port tcp $PROXY:http http \
                redirect_port tcp $PROXY:https https

$cmd 00010 allow all from any to any via lo0  # exclude loopback traffic

$cmd 00090 reass all from any to any in       # reassemble inbound packets

$cmd 00400 allow all from any to any via vnet10  # exclude LAN traffic
$cmd 00400 allow all from any to any via vnet192

$cmd 00600 deny ip from any to any not antispoof in

######################################################################
# NAT rule for incoming packets
$cmd 01000 nat 1 ip4 from any to any in recv $WAN
$cmd 01100 check-state

# Rules for outgoing traffic - allow everything that is not explicitely denied.
$cmd 02000 deny ip from not me to any 25,53 out xmit $WAN
$cmd 02100 deny ip from any to any 5353 out xmit $WAN

# Allow all other outgoing connections, i.e. skip processing to the outbound NAT rule #10000
$cmd 03000 skipto 10000 tcp from any to any out xmit $WAN setup keep-state
$cmd 03100 skipto 10000 udp from any to any out xmit $WAN keep-state

# Rules for incomming traffic - deny everything that is not explicitely allowed.
$cmd 05100 allow udp from any to me 45222 in recv $WAN keep-state

# Rules for allowing packets to services which are listening on a LAN interface behind the NAT
$cmd 06000 skipto 10000 tcp from any to any http,https in recv $WAN keep-state

# Catch any other tcp/udp packet, but don't touch gre, esp, icmp, etc...
$cmd 09998 deny log tcp from any to any via $WAN
$cmd 09999 deny udp from any to any via $WAN

####################################################################
# NAT rule for outgoing packets.
$cmd 10000 nat 1 ip4 from any to any out xmit $WAN

# Allow anything else
$cmd 65534 allow ip from any to any

Google found some information, but nothing useful how to achieve that with IPFW.
I want to access my web server on both 80 and 443 port via external IP from my LAN.

Any help very appreciated.
Thanks.
 
I'm glad you found a solution.

Just as an alternative for others passing by... in these kind of situations I've preferred to leverage local unbound instances overriding the domain names with internal addresses. If you use unbound's view facility you can return different responses based on the subnet the request comes from.
 
I don't like the ipfw nat. It's very hard to debug with dtrace and this split ingress egress nat trafic is very hard to read. I use both pf / ipfw and i think pf provide much better debugging / trace options. If you just start to learn the ipfw firewall i would recommend you to switch to pf.
 
Hehe, thanks for the advice. I agree with you.
But, For the first time, I touched FreeBSD ca. ... hmm 1998 or so and was always with IPFW, if any :D so IPFW forever :D
 
dkh said:
I'm glad you found a solution.

Just as an alternative for others passing by... in these kind of situations I've preferred to leverage local unbound instances overriding the domain names with internal addresses. If you use unbound's view facility you can return different responses based on the subnet the request comes from.
Click to expand...
totally agree, why make traffic that could remain in the internal network, go through the firewall ?
You can also tighten security that way, keep admin urls to within the local network only for example.
 
bschwand said:
totally agree, why make traffic that could remain in the internal network, go through the firewall ?
Click to expand...
It's called DMZ to provide additional separation for the services which are exposed to the Internet / public. In his topology he didn't complete the entire separation as he leave the webserver in the same vlan with the lan network. Normally LAN users are allowed to access the DMZ services/servers but the servers cannot access the LAN. This is the role of the firewall.

Here's an cisco example of this topology
 
You must log in or register to reply here.
Back
Top