02-02-2011 04:50 PM - edited 03-11-2019 12:43 PM
Hello,
I need to create a separate internal network for a classroom inside our existing lan. Topology is as follows:
separate lan - 3560 - trunk - 3560 - asa5520 - internet
My requirements are;
The separate lan will need one public ip for about 30 hosts - they will provide there own nat device
I need to be able to limit the internet bandwidth to the lan.
I would like to be able to monitor the traffic on the ASA.
I'm drawing a blank as to what the design would look like when meeting these requirements. If I just trunk a vlan all the way through I don't really have any control over it.
Any help would great.
Thanks,
Dan.
02-03-2011 07:33 AM
Dan,
Those 30 hosts with the translated IP will hit the ASA right? Once that traffic hits the ASA you have all the control over what is allowed and what is not to and from this IP address. You would have to turnk this over to the ASA.
For policing this traffic on the ASA you can refer this link: https://supportforums.cisco.com/docs/DOC-1230
QoS on the switch 3560 may even be better.
-KS
02-03-2011 09:15 AM
The part i'm confused about is the public ip management. If there nat device has the public ip and the gateway is our gateway, then the asa has no ip so i cannot manage it.
for example.
lan2 - nat device (public ip) - vlan trunked to asa - ASA5520 - (public gateway router).
The asa has no ip.
Or do I give the nat device on there lan a private ip and just port forward everthing to it and do nat on the asa as well?
They want to teach the users about nat and port forwarding, etc...so they would like to use there own router.
02-03-2011 10:20 AM
If you have only one public IP adress it will not work without severe restrictions.
If you have more than one IP address available on the network of your outside interface just configure a static for a free public IP address and make sure that "the nat device" is using this IP as its own "outside-address" and is using the ASA-Inside as a default gateway.
If the "nat device is a cisco router you will have to configure an additional static route so that "the nat device" can determine the correct outbound interface and the MAC address of the ASA inside interface for forwarding IP traffic. Something like "ip route 0.0.0.0 0.0.0.0 [ASA-inside-interface] and "ip route [ASA-inside-interface] 255.255.255.255 interface [name-of-outside-interface]".
If "the nat device" is something else you have to figure out how to add such static routes (e.g. something like "route add 0.0.0.0 mask 0.0.0.0 gateway [ASA-inside-interface]" plus "route add [ASA-inside-interface] mask 255.255.255.255 gateway [Public-IP]).
02-04-2011 05:46 PM
Wow, this would be much easier on a router, but I have to use the asa.
Currently I have two interfaces on the ASA5520. Inside and Outside. Both are routed ports. This is doing NAT for all of the internal networks that we currently have.
I will need three more public ip's for this? One on the nat device, one on the inside interface, and one on the outside interface?
So I will need to trunk a vlan into the asa and create an interface on the asa. Lets call it "inside2". This will get public ip of "123.123.123.2 The outside interface will need another public ip(123.123.123.3). And the nat device will have its own public ip (123.123.123.1). The nat device will have a default route of 0.0.0.0 0.0.0.0 123.123.123.2, the asa will have a route for traffic from 123.123.123.1 255.255.255.255 123.123.123.3.
So how do I "present" or "add" a secondary public ip address to the outside interface?
02-04-2011 05:49 PM
Ok, I found one problem with this design. The asa will not allow me to add an interface with a public ip inside the range I have becuase its already being used on the outside interface that is configured.
I have a /26 from my isp and I'm using one of those ip's on the outside interface. I have 123.123.123.10 on the outside interface with a subnet of 255.255.255.192. So now i cannot use any of those other ip's on any other interfaces.
02-05-2011 05:41 AM
Well, that is correct. Each interface should have a unique IP in a diff. subnet.
ASA - cannot add secondary IP address
ASA - cannot do PBR (policy based routing) either.
Pls. refer the doc that I wrote regarding this suggesting other options: https://supportforums.cisco.com/docs/DOC-13015/
The rest of the IP addresses you can use to translate the inside hosts and/or subnets on the ASA.
-KS
02-06-2011 09:19 AM
Hi Dan,
what I was suggesting is quite unusual and quite a dirty hack which they won't teach at school. I'm not talking about secondary IP, overlapping address-spaces or policy based routing (PBR), it's actually simpler.
I am heavily abusing the routing and neighbour discovery process which is used for IP forwarding. Remember: everything is just about finding the correct next hop and determine the outbound interface and the corresponding MAC address of the next hop. The attached document illustrates such a solution.
You can extend the config for more "public addresses" used on your "nat device" by entering additional commands on the ASA similar to:
static (inside,outside) "public.X" "public.X"
route inside "public.X" 255.255.255.255 "inside.12"
It's just a few lines of configuration so maybe it's worth the try. I couldn't try it because I don't have the environment for playing around.
This should work unless I have missed some anti-spoofing mechanisms on the ASA (the "no ip verify reverse-path" should do it in my opinion).
Rgds,
MiKa
PS: Troublshooting/verification can be done with with "show arp", "show ip route" resp. "show route", "show xlate", "show conn detailed", "show local host" and the ASA packet-tracer.
[EDIT]: I had updated the PDF (some typos) soon after posting the message please use the current
02-06-2011 10:45 AM
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.
"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?
BTW, nice drawing. Thanks for going to that extent.
02-06-2011 11:01 AM
Ok, I think I understand now how the outbound traffic will work. The nat entry that says:
static (inside,outside) public.12 public.12 will take care of that.
Thanks, I will try this sometime this week.
Dan.
02-06-2011 12:22 PM
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:
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:
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
02-06-2011 02:08 PM
Thank you again for all of the clarification.
Dan.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide