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/
On 8/11/12 11:31 AM, Kristopher Lalletti wrote:> 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 > <http://192.168.168.10> and a MASQ rule to permit outbound traffic from > 192.168.168.0/24 <http://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 > <http://1.1.1.1/24> is the target public IP desired: > > WAN==>[eth2:wan:1.1.1.1/24==(frontend <http://1.1.1.1/24==(frontend> > firewall)==>eth3:dmz:?.?.?.?==>]==>1.1.1.1/24 <http://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.1) Configure the WAN interface as 1.1.1.1/32 2) Add an explicit host route out of the WAN interface to the upstream router. 3) Configure the DMZ interface as 1.1.1.1/24 4) Set the proxy_arp option in the /etc/shorewall/interfaces entry for both the WAN and DMZ interfaces. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/
On 8/11/12 12:17 PM, Tom Eastep wrote:>> 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. > > > 1) Configure the WAN interface as 1.1.1.1/32 > 2) Add an explicit host route out of the WAN interface to the upstream > router. > 3) Configure the DMZ interface as 1.1.1.1/24 > 4) Set the proxy_arp option in the /etc/shorewall/interfaces entry for > both the WAN and DMZ interfaces. >One more thing -- if you don''t need to firewall the WAN/DMZ traffic, you can simply bridge them and assign address 1.1.1.1/32 to the bridge. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/