Hi Dan,
I stick with my example so I don't get confused, please substitute any prefixes with your environment.
dan.letkeman wrote:
I still don't see how the outbound traffic can be seen as coming from the ip address of the nat device. It would be double natted at the ASA if you are routing all of the traffic through a connected network to the existing asa inside interface.
Let's distinguish outbound from inbound traffic, outbound looks as follows:
The "nat device" is unaware of the tricks we are playing. Traffic originating from the "nat device" will use the IP and MAC address of eth0/0 from "nat device" as the source IP/MAC and whatever destination on the internet as the destination IP. If the "nat device" is doing some NAT on it's own, it will use the configured global IP of the configuration. For my example the global IP on the "nat device" should be "ethernet 0/0 overload" instead of a configured global pool.
The routing configured on the "nat device" (the two statics) will ensure that this traffic is forwarded to the MAC address of the inside interface of the ASA. The src IP/MAC of the traffic will originate from the "nat device" using so-to-say an "alien source IP" which means the source IP is not homed on the connected network of the ASA. That's no problem, the ASA can handle that as long as anti-spoofing and reverse path verification is disabled.
dan.letkeman wrote:
"The ASA has suffient information (NAT and routing) to forward packets from "nat device" to the internet." How? If you are routing to the connected network the outbound traffic will use the same nat rules as everything else. It will not preserve the public ip on the nat device. It will hide it behind the asa right?
Maybe here is a little misconception: The ASA receives a packet with a source IP/MAC of the "nat device" and a dst MAC of the ASA inside interface and dst IP on the internet or somewhere on the outside. The ASA will do a couple of lookups to decide what to do:
- Do I have a route for the destination and what would be the outbound interface for that packet?
-> Result: outside interface, default gateway. - Do I have a NAT rule for that packet with that src/dst IP and that interface combination?
-> Result: static (inside,outside) "public.12" "public.12", means that neither src or dst IP will be translated. There is no rule to hide the IP address "public.12" of the "nat device" behind the IP address of the ASA. - Is the security level of the incoming interface higher than the outgoing interface for that packet?
-> Result: Yes, use the static for the packet respectively the connection. - Are there any restrictions like access-list deny, anti-spoofing, reverse-path-verify?
-> Result: Hopefully not, build a translation in the XLAT table (if not done already) and build a connection in the connection table. Forward the packet on the outside interface. This packet will have the original src IP of the "nat device" and of course the src MAC of the ASA outside interface. The dst IP is unchanged and the destination MAC is what ever the ASA determines according to the ASA's routing and ARP table.
- The ISP gateway will recieve a packet with the original, untranslated IP and forwards the packet to the internet.
dan.letkeman wrote:
I currently have:
client1( 172.16.16.3) -- network (172.16.16.0/24) -- asa inside (172.16.16.1) -- asa outside (123.123.123.2) -- isp gw (123.123.123.1)
That's exactly what we are going to change, see below:
dan.letkeman wrote:
If i understand what you are trying to say:
nat device (123.123.123.3) -- network (172.16.16.0/24) -- asa inside (172.16.16.1) -- asa outside (123.123.123.2) -- isp gw (123.123.123.1)
Except you would route the traffic out the connected interface on the nat device and the asa would static nat the public ip(123.123.123.3) with the public ip(123.123.123.3)......
Pretty much, just that I used different addresses in my example: "public.12" would be "123.123.123.3", "inside.1" would be "172.16.16.1" and so on...
dan.letkeman wrote:
Where does the isp gw come into play? on the ASA,
Exactly, the IP of the ISP gw would only be known to the ASA, it should be covered with a "route outside 0.0.0.0/0 [IP-of-ISP-gateway]".
dan.letkeman wrote:
but then it would still be seen as coming from 123.123.123.2
Maybe that's also a misconception, the traffic will come from the outside interface of the ASA but only on layer 2: The outbound traffic on the outside interface would be:
- Layer 3: unchanged src IP of your "nat device" which is "public.12" in my example or "123.123.123.3" in your example because of the "static (inside,outside) [IP] [IP]" command, sometimes referred to as "identity NAT" or "NAT excemption".
- Layer 3: unchanged dst IP of the original packet because the destination lies on a lower security level, this is the default behaviour of the ASA.
- Layer 2: src MAC of the ASA outside interface, this is standard routing principles.
- Layer 2: dst MAC of the ISP gateway, determined through the ARP table.
dan.letkeman wrote:
I wish I had an asa to play with. Sorry i'm still confused
Unfortunately I also don't have an ASA to play with, but I have succesfully done similar stunts in the past.
I hope the confusion is now gone
dan.letkeman wrote:
I had a suggestion on a different forum about using multiple contexts... maybe that would work better.
WHOOHAA, don't make things over-complicated. Even with multiple contexts you would run into similar issues if the contexts are routed. And if one of the contexts would be transparent (which would be the solution at hand): Transparent Contexts CANNOT share physical interfaces with other contexts (according to the documentation). Which means you would need to completely redesign your outside network, physically and maybe even logically, juggling with VLANs and external switches and who-knows-what.
Also you loose many features in multiple context mode.
dan.letkeman wrote:
BTW, nice drawing. Thanks for going to that extent.
Thx for the compliment, I started to get interested in the case, it's some kind of "sport" for me, it exercises my creativity....
Rgds, MiKa
