Welcome to Soft32 Linux Forums!
FAQFAQ    SearchSearch      ProfileProfile    Private MessagesPrivate Messages   Log inLog in

Reverse NAT and Masquerade Question

  
   Soft32 Home -> Linux2 Arch -> Security RSS
Next:  GPG: Invalid character  
Author Message
Steven J. Hathaway

External


Since: Oct 12, 2006
Posts: 13



(Msg. 1) Posted: Sun Jun 22, 2003 3:28 pm
Post subject: Reverse NAT and Masquerade Question
Archived from groups: comp>security>firewalls, others (more info?)
This is a network feasibility question.

Do you know which of the following firewalls can perform a reverse
address translation?

Checkpoint Firewall-1
Netfilter (IPtables)
CISCO IOS Firewall
CISCO PIX Firewall

The issue is to map a specific external IP address or transport domain
address onto a
local network IP address. The result of which would allow a workstation
or server on the
local network to establish a session to a remote host by virtue of
addressing data to the
virtualized local IP address.

-- -- Discussion -- --

What are the problems (other than address spoofing attacks) to implement
a reverse
NAT capability on firewalls? Can IPsec ESP function properly given the
address
deployment usage defined in the example later in this discussion?

The current internal-external paradigm used by most firewall
configurations provides
communications to a remote host when the client specifies the remote
global address.
I need the ability for a local user to use a local address to reach a
remote host or
server, thus protecting the internal network from unwanted external
addresses or
transport addresses, and still provide a communications path.

The purpose is to establish a secure data transport domain, using IP
addresses
from the "link local" block of 169.254.0.0/16 [RFC:3330] and keep these
addresses
invisible to the connected LANs, WANs, Internet, National Service
Domains,
and the private IP space of [RFC:1918].

I have a need to link the public safety resources served by 240
separately administered
private network address domains, many of which have conflicting IP
address assignments
in the blocks assighed via RFC:1918 for private networks. I have been
unable to
obtain registered IP network assignments of sufficient host address
space to
accommodate the unique addressing of data transport traffic. Can the
"link local"
block of 169.254.0.0/16 [RFC:3330] be used for this purpose?

Another network project under discussion will link the secure resources
of 15,000 to
45,000 separately administered networks across North America using the
"link local"
block address space. One of the major problems here will be the
maintenance of
host-based routing tables and the many forward-nat and reverse-nat
traffic
configuration and policy management tables. This network will not be
served by
the Internet backbones, but some segments may tunnel through the
Internet. Most
of the clients will have Internet access for general traffic, but this
network
is for the transport of secure and time-sensitive traffic with the
ability to be
managed by a diversified management infrastructure. This project may
also be a
candidate for IPv6 technology when many of the current experimental
issues are
resolved and technology becomes commercially available at comodity
prices.

Using the "link local" block from RFC:3330 will require a reverse
address translation,
at all border forewall-routers, to accommodate the required policy
routing and
protection of the connected public and private address domains. The
"link-local"
address block shall not be routed into the public Internet or the
private networks,
but is used to provide transport across a semi-private wide-area
network.

A related question (IPsec) - Is there a configuration policy that would
allow
encryption protected communications between end nodes in two local
networks,
sharing the same local address space, each with reverse-nat firewalls to
a
transport address domain?

Would deployment of "link-local" 169.254.0.0/16 address space be
permitted for
these applications as an acceptable use? Documentation currently states
that
this network block is for link-local autoconfiguration in absence of
DHCP.
Our use would restrict the addresses to a "transport" network, whose
addresses
are invisible to the Internet and connected local networks.
Communications
will require firewall/router devices capable of both forward-nat and
reverse-nat
capabilities.

Is there a chance that the "link-local" address space could be
reassigned as
public addresses to be routable on the Internet?

My proposed projects require an address space that is administratively
unique
from the private address space of RFC:1918, with an additional
requirement that
this address space not be routable to the Internet, or compromized by
routes
in the connected private networks.

Example Deployment of "link local" address block for a transport network

keeping the integrity of local private networks and address isolation of
the
transport network.

Private A

Wks-A1 192.168.185.101 - forward masquerade
to address on transport "link-local" address block

Srv-A1 192.168.185.11 - forward nat
to transport "link-local" address

(Srv-B1) 192.168.185.222 - reverse-nat (from 169.254.2.2)
from transport "link-local" address

(Msq-B1) 192.168.185.221 - reverse-nat (from 169.254.2.1)
from transport "link-local" address

Private B

Wks-B1 192.168.185.101 - forward masquerade
to address on transport "link-local" address block

Srv-B1 192.168.185.11 -forward nat
to transport "link-local" address

(Srv-A1) 192.168.185.222 - reverse-nat (from 169.254.1.2)
from transport "link-local" address

(Msq-A1) 192.168.185.221 - reverse-nat (from 169.254.1.1)
from transport "link-local" address

Transport "Link-Local" Address Block (Transport Side of Firewall)

Msq-A1 169.254.1.1 - forwared masquerade for Network-A
workstations
into the "link-local" transport address domain

Srv-A1 168.254.1.2 - forward basic NAT for Network-A server
into the "link-local" transport address domain

(internal-routing)

Msq-B1 169.254.2.1 - forward masquerade for Network-B
workstations
into the "link-local" transport address domain

Srv-B1 168.254.2.2 - forward basic NAT for Network-B server
into the "link-local" transport address domain

-------------------
Steven J. Hathaway
Communications Engineer
Back to top
Login to vote
Allen Kistler

External


Since: Jun 23, 2003
Posts: 22



(Msg. 2) Posted: Mon Jun 23, 2003 9:51 am
Post subject: Re: Reverse NAT and Masquerade Question [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
Steven J. Hathaway wrote:
> This is a network feasibility question.
>
> Do you know which of the following firewalls can perform a reverse
> address translation?
>
> Checkpoint Firewall-1
> Netfilter (IPtables)
> CISCO IOS Firewall
> CISCO PIX Firewall
>
> The issue is to map a specific external IP address or transport domain
> address onto a
> local network IP address. The result of which would allow a workstation
> or server on the
> local network to establish a session to a remote host by virtue of
> addressing data to the
> virtualized local IP address.
>
> [snip]

They can all do one-to-one NAT. Depending upon how your ISP connection
is configured, you may also need to set up proxy arp for the "virtual"
addresses (if they're truly virtual).

One-to-one means just that. One external address to one internal
address. There's no dynamic remapping like many-to-one (10.x internal
with a single external). So if you want a bunch of machines to be
visable externally, you need that many IP addresses, generally.
(Sometimes you can overlap if each internal machine offers different
services, but that's getting a bit trickier than your question.)
Back to top
Login to vote
Steven J. Hathaway

External


Since: Oct 12, 2006
Posts: 13



(Msg. 3) Posted: Mon Jun 23, 2003 4:53 pm
Post subject: Re: Reverse NAT and Masquerade Question [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
Allen Kistler wrote:

> Steven J. Hathaway wrote:
> > This is a network feasibility question.
> >
> > Do you know which of the following firewalls can perform a reverse
> > address translation?
> >
> > Checkpoint Firewall-1
> > Netfilter (IPtables)
> > CISCO IOS Firewall
> > CISCO PIX Firewall
> >
> > The issue is to map a specific external IP address or transport domain
> > address onto a
> > local network IP address. The result of which would allow a workstation
> > or server on the
> > local network to establish a session to a remote host by virtue of
> > addressing data to the
> > virtualized local IP address.
> >
> > [snip]
>
> They can all do one-to-one NAT. Depending upon how your ISP connection
> is configured, you may also need to set up proxy arp for the "virtual"
> addresses (if they're truly virtual).
>
> One-to-one means just that. One external address to one internal
> address. There's no dynamic remapping like many-to-one (10.x internal
> with a single external). So if you want a bunch of machines to be
> visable externally, you need that many IP addresses, generally.
> (Sometimes you can overlap if each internal machine offers different
> services, but that's getting a bit trickier than your question.)

My problem is not the forward-nat addressing that firewall devices implement.

Reverse-nat is independent of the number of IP addresses a service provider
gives you for communications. Dial-up point-to-point connections with
dynamic IP assignment should also work.

A trivial example of what I am looking for is to allow local machines to
access an external DNS server without having to know its public IP address
or DNS name. All the local machines need to do is to place in their
configuration files the virtual local IP address that is NAT translated
to some external DNS.

Then when the remote DNS fails - functionality can be restored by creating
another reverse=nat mapping to a functional DNS elsewhere. I then do not
have to reconfigure the local machines for DNS access.

My true requrements go beyond this trivial DNS example.

- Steve Hathaway
Back to top
Login to vote
no body

External


Since: Jul 09, 2003
Posts: 17



(Msg. 4) Posted: Tue Jun 24, 2003 6:08 pm
Post subject: Re: Reverse NAT and Masquerade Question [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
> A trivial example of what I am looking for is to allow local machines to
> access an external DNS server without having to know its public IP address
> or DNS name. All the local machines need to do is to place in their
> configuration files the virtual local IP address that is NAT translated
> to some external DNS.
>
> Then when the remote DNS fails - functionality can be restored by creating
> another reverse=nat mapping to a functional DNS elsewhere. I then do not
> have to reconfigure the local machines for DNS access.

iptables that comes with the 2.4 kernel can do that. We have a Linux
Security Server set up (from www.ComputerSecurityResearch.com, if that
matters) that does the DNAT just as your example needs. All the internal
boxes have their DNS pointing to the security server, and it in turn it
DNATs the DNS requests out to the current DNS server. If that DNS server
starts acting buggy we just make one change on the security server and all
the clients benefit from the change. Sounds like just what you need.

Now here's one hitch I can see, and I see the way around it. Let's say you
have networks A and B, each with more than one machine, and each with only
one public IP (or IP that will be used to link them together). So computer
A.1 wants to connect to B.1, the security server for A correctly changes the
destination IP to B's public IP. B's security server gets this packet and
doesn't know which internal computer to send it to.

The way around it is what we've done with this security server. A's and B's
security servers create an IPSEC tunnel between them and have route entries
that say "anything for B's net - route to B's IPSEC IP" and likewise for A.
Works like a charm because their isn't any DNAT involved. You wouldn't need
the tunnel, we just needed the data to be secure between the networks.

In the case where you have A, B, and C *and* two networks (say B and C) have
the same private address range, you have the combination of the two examples
above put together. A's network thinks B's and C's networks are actually
different, and a DNAT translation happens on B's and C's security servers.
What you end up with is a "global address map" that says network A has this
"public" range (not true public, but only used once within all your
networks), B has this "public" range, etc... Then anything destined for A
will be addressed to that "public" range, and A's security server is
expected to do the DNAT to the real internal IP address.

It's complicated, but it works. And none of our local nets had to get
renumbered.

One thing that stinks is the one-to-one NAT. Each box has one line DNAT,
and one line SNAT per internal IP. The nice thing here is the only NAT is
happening on the security server responsible for those IPs. This lets us
add more IPs to a network without having to go change all the security
servers, we just change the one that manages that network. And the load of
doing the NAT is on the local security server, so if we have a new local
network with thousands of IPs, we get a more powerful (as in CPU/mem)
security server just for that network, we don't have to upgrade the whole
infrastructure to support the increase in NATs of more IPs. That security
server is the only one that realizes the load of those additional IPs and
their resultant NATs.
Back to top
Login to vote
Steven J. Hathaway

External


Since: Oct 12, 2006
Posts: 13



(Msg. 5) Posted: Wed Jul 02, 2003 6:19 pm
Post subject: Re: Reverse NAT and Masquerade Question [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
no body wrote:

> > A trivial example of what I am looking for is to allow local machines to
> > access an external DNS server without having to know its public IP address
> > or DNS name. All the local machines need to do is to place in their
> > configuration files the virtual local IP address that is NAT translated
> > to some external DNS.
> >
> > Then when the remote DNS fails - functionality can be restored by creating
> > another reverse=nat mapping to a functional DNS elsewhere. I then do not
> > have to reconfigure the local machines for DNS access.
>
> iptables that comes with the 2.4 kernel can do that. We have a Linux
> Security Server set up (from www.ComputerSecurityResearch.com, if that
> matters) that does the DNAT just as your example needs. All the internal
> boxes have their DNS pointing to the security server, and it in turn it
> DNATs the DNS requests out to the current DNS server. If that DNS server
> starts acting buggy we just make one change on the security server and all
> the clients benefit from the change. Sounds like just what you need.
>
> Now here's one hitch I can see, and I see the way around it. Let's say you
> have networks A and B, each with more than one machine, and each with only
> one public IP (or IP that will be used to link them together). So computer
> A.1 wants to connect to B.1, the security server for A correctly changes the
> destination IP to B's public IP. B's security server gets this packet and
> doesn't know which internal computer to send it to.
>
> The way around it is what we've done with this security server. A's and B's
> security servers create an IPSEC tunnel between them and have route entries
> that say "anything for B's net - route to B's IPSEC IP" and likewise for A.
> Works like a charm because their isn't any DNAT involved. You wouldn't need
> the tunnel, we just needed the data to be secure between the networks.
>
> In the case where you have A, B, and C *and* two networks (say B and C) have
> the same private address range, you have the combination of the two examples
> above put together. A's network thinks B's and C's networks are actually
> different, and a DNAT translation happens on B's and C's security servers.
> What you end up with is a "global address map" that says network A has this
> "public" range (not true public, but only used once within all your
> networks), B has this "public" range, etc... Then anything destined for A
> will be addressed to that "public" range, and A's security server is
> expected to do the DNAT to the real internal IP address.
>
> It's complicated, but it works. And none of our local nets had to get
> renumbered.
>
> One thing that stinks is the one-to-one NAT. Each box has one line DNAT,
> and one line SNAT per internal IP. The nice thing here is the only NAT is
> happening on the security server responsible for those IPs. This lets us
> add more IPs to a network without having to go change all the security
> servers, we just change the one that manages that network. And the load of
> doing the NAT is on the local security server, so if we have a new local
> network with thousands of IPs, we get a more powerful (as in CPU/mem)
> security server just for that network, we don't have to upgrade the whole
> infrastructure to support the increase in NATs of more IPs. That security
> server is the only one that realizes the load of those additional IPs and
> their resultant NATs.

Another project I am working with is a backend secure or top-secret
capable network that will handle traffic to 15,000 - 35,000 separately
administered private networks. I am finding it extremely difficult to acquire
public registered IP addresses in North America for each security server
to NAT address its resources. Many of the 15,000 - 35,000 networks
will have conflicting private addresses. This secure private backbone
will not be connected to the Internet.

I am toying with the idea of using a registered address space
allocated to some other continental IP registry for use in this
virtual link-layer backbone. With appropriate NAT policy, the local
network attached devices, except for the security access servers,
will have no knowledge of the link-layer backbone transport network.
All services advertized by NAT to the link-layer backbone will
be reverse-NAT advertized into each local network as a virtualized
local IP address.

I cannot use the "link-layer" address block reserved by IANA
because the special use is for development of zeroconf IPv4
devices. The operation of these devices on the "link-layer"
address block makes the address space unusable for the secure
backbone service.

IPsec-ESP has problems if the tunnel endpoints are address-translated.

With the "link-layer" transport in question, and that security devices
have both forward NAT and reverse NAT to protect and isolate
the addressing zones, IPsec operations fail.

Local Network A

Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]

Local Network B

Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]

Without encryption, Host-A can communicate with Host-B by addressing
Virtual Host A'

Without encryption, Host-B can communicate with Host-A by addressing
Virtual Host B'

Attempts to link Network A and Network B with IPsec, and other IP tunnel
protocols fails because of the network address translation issues.
Tunnel technology currently requires Network A and Network B tunnel
endpoints to be in separate IP address zones (not sharing the same subnet
or IP addresses).

What will work for security is the use of SSL or TLS at the application
interface to a communications path suchas TCP or IP-Stream. But there are
currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
protocols that are compatible with the endpoints being address translated.

- Steve Hathaway
Back to top
Login to vote
no body

External


Since: Jul 09, 2003
Posts: 17



(Msg. 6) Posted: Thu Jul 03, 2003 2:48 am
Post subject: Re: Reverse NAT and Masquerade Question [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
> Another project I am working with is a backend secure or top-secret
> capable network that will handle traffic to 15,000 - 35,000 separately
> administered private networks. I am finding it extremely difficult to
acquire
> public registered IP addresses in North America for each security server
> to NAT address its resources. Many of the 15,000 - 35,000 networks
> will have conflicting private addresses. This secure private backbone
> will not be connected to the Internet.

Woah, looks like you have a big project. Need a security tech to help you
out?

> I am toying with the idea of using a registered address space
> allocated to some other continental IP registry for use in this
> virtual link-layer backbone.

It doesn't sound to me like you need it. Why get all "real" public IPs when
you're not connected to the Inet and won't need to worry about their traffic
being routed on the Inet? What your project sounds like to me is one large
private network that connects many many private networks. I'm not sure
where the Inet comes into play here. And if it's not involved, why worry
about the expense and headache of having to find/buy enough public IPs to
pull this off?

How about this model. One huge network. If you use the private class A
10.x you get 16 million IP addresses. That should be more than enough for
you, unless you have 35,000 networks and each network has more than an
average of 479 IPs (if this is the case you go to model 2). Each computer
has it's current "real" IP plus it's virtual 10.x IP. Your security
gateways perform the NAT back and forth. This works foolproof with all
protocols including IPSec-ESP (more on that below). Each security gateway
is responsible for correctly routing the 10.x network, and anything with the
virtual IP destination of it's internal computers it DNATs to the correct
internal computer. And then it SNATs everything going out, one-for-one.
Each computer inside gets SNATed to it's own personal 10.x virtual IP.

> With appropriate NAT policy, the local
> network attached devices, except for the security access servers,
> will have no knowledge of the link-layer backbone transport network.

Sounds like you are thinking of a little bit different model. You envision
one routing network and 35,000 private nets joined by this routing network.
Your NAT will only NAT to the gateway (security server) IPs, thus prevent
some protocols (namely IPSec-ESP) from working in some situations (more
below). The model I give above is much better and doesn't have this problem
because in my model *every machine has it's own "routing network" IP*.

> All services advertized by NAT to the link-layer backbone will
> be reverse-NAT advertized into each local network as a virtualized
> local IP address.
>
> I cannot use the "link-layer" address block reserved by IANA
> because the special use is for development of zeroconf IPv4
> devices. The operation of these devices on the "link-layer"
> address block makes the address space unusable for the secure
> backbone service.

Can you explain why? Thanks.

>
> IPsec-ESP has problems if the tunnel endpoints are address-translated.

This is half true. Let's talk about the typical user with several internal
boxes, one NATing gateway to the Internet. And for the sake of argument
let's say that gatway can correctly NAT IPSec (like linux). Internal box A
want's to IPSec to external box X. The gateway NATs the source address to
B, the external IP of the gateway. X thinks it's talking to B and replies
back as such. The gateway DNATs the IPSec back to box A. It's all
transparent and it all works. Now internal box C wants to talk to Y, and
the gateway NATs these packets the same as before. Although IPSec is proto
50 (with no concept of a port) and ESP is port 500 on both ends the gateway
can keep the conversations separate by the external end of the connection.
So in this sense your above statement is false. I have systems right now
that have their end-points NATed and they talk to eachother via IPSec.

Everything will work fine as long as no two computers inside try to IPSec to
the same server on the outside. This is the fault of having both ends of
the ESP set to UDP port 500 and the fact that IPSec is one whole protocol.
If different ports could have been used on the client side and IPSec was
session aware this wouldn't be a problem, but it's not that way so two
internal systems in our above example can't IPSec to the same external
system. So in this sense your above statement is true.

The work around in this example is you get one public IP per internal box
that will IPSec. And any IPSec coming from that box gets SNATed to it's
specific public IP. Then as many boxes as have their own public IP NAT will
be able to connect to the same IPSec server on the outside. And this is how
we make your statement above back to not being true.

This translates to one virtual IP per computer in your model. That's how
you get IPSec to work for your setup and invalidate your above statement.

> With the "link-layer" transport in question, and that security devices
> have both forward NAT and reverse NAT to protect and isolate
> the addressing zones, IPsec operations fail.
>
> Local Network A
>
> Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
> Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]
>
> Local Network B
>
> Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
> Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]
>
> Without encryption, Host-A can communicate with Host-B by addressing
> Virtual Host A'
>
> Without encryption, Host-B can communicate with Host-A by addressing
> Virtual Host B'
>
> Attempts to link Network A and Network B with IPsec, and other IP tunnel
> protocols fails because of the network address translation issues.

Only in your model. So throw that model away and get one that works, like
the one I proposed. It will work. I have it working right now.

> Tunnel technology currently requires Network A and Network B tunnel
> endpoints to be in separate IP address zones (not sharing the same subnet
> or IP addresses).

That's only if you don't (a) NAT and/or (b) have a separate virtual IP for
each box.

> What will work for security is the use of SSL or TLS at the application
> interface to a communications path suchas TCP or IP-Stream. But there are
> currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
> protocols that are compatible with the endpoints being address translated.

????? My above example shows that IPSec would work. And that's not just
theory. I have it working right now. You can say all you want that it
doesn't work, but its working right now. Maybe I'm fooling myself and don't
really understand what you are saying.

And what about ppp over ssh? I also do that to without any problems. As
matter of fact I set my ppp/ssh network up as a WAN that securly routes
between several private networks. And each of these private networks have
only one public IP. And they NAT between them using the ppp/ssh IPs.
Back to top
Login to vote
Display posts from previous:   
Related Topics:
Reverse DNS PTR - Tried posting this on comp.protocols.dns.bind like 3 times already but that stupid "moderated" forum won't ap...

reverse mapping and ssh - Hello, can ssh be set up in a way so that a connection can only be established when : [1] : the host that is trying....

Question - I keep getting these entries in my /var/log/messages every 5 minutes or so. Can someone help me decipher what this is..

Possible Trojan Question - I posted this to a.o.l.s but haven't had any replies yet so I'll ask here. Problem: I have installed Slackware-curren...

vsftpd question - hi all, i've recently got rid of WU and moved to vsftpd. i was wondering is someone could help me with the following..

Apache question. - I recently upgraded apache to the latest 1.3.29 release and now I am wondering if something has been changed to allow....
       Soft32 Home -> Linux2 Arch -> Security All times are: Pacific Time (US & Canada) (change)
Page 1 of 1

 
 You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Categories:
 Windows
 Linux
 Mac
 PDA

[ Contact us | Terms of Service/Privacy Policy ]