Hi all,
I’m dabbling with the idea of establishing what could be considered a
bridged-nat scenario. Which, in fact, is a contradiction in terms, but the
whole reason behind it is that I’m experimenting with IPv6 6RD deployment
from my ISP, and I needed a Linux 2.6.33 Kernel with 6RD_SIT interface to
which my current firewall does not provide.
So I’ve created what could be considered a “man-in-the-middle” firewall
which leverages the IPv6 6RD tunnel with configuration provided by DHCPv4,
and routes IPv6 through the LAN interface, then DNATs everything else to
the legacy firewall.
Basically, here’s the scenario:
- eth0 is the “lan” interface, which is only used for
administration (no traffic routes here)
- eth2 is the “wan” interface, receives an IP address via DHCP
from the ISP
- eth3 is the “dmz” interface, presents an IP address via DHCP to
my Firewall
Right now I’ve got my first iteration functional; having IPv6 traffic
working via the LAN interface (thanks to radvd, and shorewall6), and my DMZ
interface is an RFC-1918 IP (192.168.168.1) which offers a DHCP address
192.168.168.10 to my firewall, and a combination of a vanilla DNAT rule to
forward all inbound WAN traffic to dmz/192.168.168.10 and a MASQ rule to
permit outbound traffic from 192.168.168.0/24 via eth2.
So far, so-good, and everything works nicely. Now I want to build onto
this, and move-on to the next objective; abolish the rfc1918 IP for the
backend firewall, and selectively pass-through the frontend public IP while
retaining functionality on the front-end firewall (since it needs to
establish its IPV6 SIT 6RD tunnel). Essentially, making the front-end
firewall transparent to the backend firewall.
Here’s the “impossible” flow sequence, where 1.1.1.1/24 is the target
public IP desired:
WAN==>[eth2:wan:1.1.1.1/24==(frontend firewall)==>eth3:dmz:?.?.?.?==>]==>
1.1.1.1/24 (backend firewall with default gateway being ??)
Get the gist? Ideas/orientations would be appreciated. This concept is
inspired from an old Mediatrix 1102 VOIP ATA, to which their solution to
QOS was to be the front-end device to the WAN, yet not impede on existing
network topoogy, by passing-through the WAN public IP to the backend device
in a very clever way.
Cheers
Kris
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
