cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1798
Views
0
Helpful
21
Replies

ASA 5505 to allow 2nd network segment through mpls

Dennis Newman
Level 1
Level 1

I have been having a heck of a time trying to configure my 5505 to allow the second segment on my network to use the internet.

Office 1 has a fiber internet connection, and all traffic flows fine.

Office 2 had gotten it's internet from AT&T, via a network based firewall injecting a default route into the mpls cloud.

both offices connunicate to each other through the mpls.

When we added the fiber to office 1, we had the mpls people change the default internet route to the inside address of the 5505 and things worked fine.

when AT&T attempted to remove the NBF defaut route, and inject the 5505's address as default, things didn't go so well.

AT&T claims that it is within my nat cmmands on the 5505, but won't tell me anything else.  I assume that they are correct, and I assume that I am not good enough with the 5505 ASDM to tell it what to do.

Office 1 uses 10.10.30.xx addresses and Office 2 uses 10.10.10.xx - the 5505 inside interface is 10.10.30.2 the internal interfaces of the mpls are 10.10.30.1 and 10.10.10.1

I don't know what other information you would need, but am stuck here at Office 1 until I can get this working.

Thanks

1 Accepted Solution

Accepted Solutions

Hi,

Ok, so IF I have not understood anything wrong (which is still possible ), it would seem to me that the network mask of the ASA is atleast one reason that will cause problems for WI LAN if they try to use the Internet through the ASA5505 on the PA site.

This is what I would presume will happen when a host on the WI LAN initiates a connection to the Internet

  • WI PC 10.10.10.10 sends a TCP SYN to initiate/open a TCP connection with a Web server on the Internet
  • The TCP SYN gets forwarded to the default gateway of the PC which is 10.10.10.1
  • The TCP SYN packet traverses the ISP MPLS network all the way to the PA Site
  • The PA Site 3900 has a default route probably towards PA ASA 10.10.30.2
  • TCP SYN gets forwarded from the PA 3900 to the PA ASA according to the above mentioned default route on the PA 3900
  • TCP SYN arrives on the ASA and gets forwarded to the Internet
  • TCP SYN,ACK from the Web server arrives on the ASA
  • ASA will ARP for the MAC address of the WI PC IP address of 10.10.10.10 because it thinks that the host is directly connected to the ASAs "inside" interface because of the "inside" interfaces large /16 network mask which contains addresses between 10.10.0.0 - 10.10.255.255
  • The ARP request sent from the ASA never receives a reply since the WI PC isnt directly connected
  • PA ASA will never be able to forward the traffic to the WI PC which is trying to open the connection to the Internet because of the above mentioned problem. Therefore the TCP connection from WI PC never succeeds and timeouts.

Now you might ask, why does the connections between the PA and WI LAN work. To my understanding is that because the traffic from the PA hosts gets first forwarded to the PA 3900 then they have a working route to the WI LAN. The same way the WI LAN has a working route towards the PA LAN since the ASA isnt not involed in anyway.

The PA Internet connection naturally works as the 10.10.30.0/24 hosts are directly connected to the ASA so the above mentioned ARP will not fail on their part and traffic is forwarded just fine between the PA LAN and the Internet.

So to my understanding the solution to this problem would be to change the PA ASA "inside" subnet mask from 255.255.0.0 to 255.255.255.0.

If you are unsure of the of this change I would suggest you do it when there is low network use (so you can revernt the change) Naturally if you are on the PA LAN then you can probably access the Console connection if something were to go wrong. I cant see any configurations on the PA ASA which would imply that you configure the device remotely through the Internet.

Hope I made sense and hope this helps

Naturally ask more if needed

- Jouni

View solution in original post

21 Replies 21

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Would it be possible to get some simple drawing of the current problematic topology?

- Jouni

Attached are a PDF file showing the old to new diagrams, and a txt file showing my current ASA configuration.

If there is anything else you need, I will be happy to send it.

Thank You

Hi,

I am still not quite sure about the sites connectivity where the ASA resides.

Though one thing that caught my eye is that you are using the mask /16 in the ASA "inside" interface. If the ASA is supposed to route traffic destined to 10.10.10.0/24 to somewhere else then this mask will cause problems atleast.

ASA will think that the hosts 10.10.10.x are directly connected to its "inside" interface and will try to ARP for their MAC address rather than forward traffic somewhere.

Also the static routes configured on the ASA seem strange. They only use host mask /32. Naturally these routes arent in use at the moment since the ASA "inside" interface is /16. You might want to consider changing the mask to /24 unless I understood something about the network setup incorrectly?

- Jouni

The ASA sits on the switch in the PA office (the same one that the PA users are connected to) this switch has the PA MPLS router (10.10.30.1) attached to it as well. so traffic from 10.10.10.xx comes along through the MLS to 10.10.30.1, which decides if it needs to go to a 10.10.30.x server, or to the internet via 10.10.30.2 (the ASA) so the only traffic that the ASA "should" see is internet traffic. Unless this 57 year old IT guy is just way out in left field with these "newfangled" devices

A few years ago, we had the opposite situation, all PA traffic came to WI through the MPLS and out to the internet via an AT&T DIA - but that was all managed by AT&T and didn't require me to maintain my own firewall.

I probably should have popped for something a little more expensive than the ASA 5505 but my budget was tight at the time.

The two objects "bloomsburg /24" and "cottagegrove /24" aren't actually used anywhere in the ACL's I had put them in in an attempt to follow a comment from an AT&T tech  The Inside network was defined as subnet 255.255.0.0 because I assumed that would be necessary to allow both 10.10.10.x and 10.10.30.x traffic.  I may have messed that up in the original configuration, but as it sits now - the PA office can "talk" with both the internet, and with the WI network.

Dennis

Hi,

Can you confirm where the hosts on PA network 10.10.30.0/24 get their IP addresses from?

Is it from the PA 3900 or the PA ASA? Though more interested in which of the devices is acting as the default gateway for the PA network 10.10.30.0/24

- Jouni

Gah,

Naturally the hosts wont get the IP addresses from the ASA as I can see that the ASA is not configured for DHCP

So either the PA 3900 is acting as a DHCP server or you have an internal DHCP server in the PA network?

- Jouni

Sorry - yes the PA 3900 is the DHCP for 10.10.30.x subnet and the WI 2800 provides it for the 10.10.10.x subnet

Hi,

Ok, so IF I have not understood anything wrong (which is still possible ), it would seem to me that the network mask of the ASA is atleast one reason that will cause problems for WI LAN if they try to use the Internet through the ASA5505 on the PA site.

This is what I would presume will happen when a host on the WI LAN initiates a connection to the Internet

  • WI PC 10.10.10.10 sends a TCP SYN to initiate/open a TCP connection with a Web server on the Internet
  • The TCP SYN gets forwarded to the default gateway of the PC which is 10.10.10.1
  • The TCP SYN packet traverses the ISP MPLS network all the way to the PA Site
  • The PA Site 3900 has a default route probably towards PA ASA 10.10.30.2
  • TCP SYN gets forwarded from the PA 3900 to the PA ASA according to the above mentioned default route on the PA 3900
  • TCP SYN arrives on the ASA and gets forwarded to the Internet
  • TCP SYN,ACK from the Web server arrives on the ASA
  • ASA will ARP for the MAC address of the WI PC IP address of 10.10.10.10 because it thinks that the host is directly connected to the ASAs "inside" interface because of the "inside" interfaces large /16 network mask which contains addresses between 10.10.0.0 - 10.10.255.255
  • The ARP request sent from the ASA never receives a reply since the WI PC isnt directly connected
  • PA ASA will never be able to forward the traffic to the WI PC which is trying to open the connection to the Internet because of the above mentioned problem. Therefore the TCP connection from WI PC never succeeds and timeouts.

Now you might ask, why does the connections between the PA and WI LAN work. To my understanding is that because the traffic from the PA hosts gets first forwarded to the PA 3900 then they have a working route to the WI LAN. The same way the WI LAN has a working route towards the PA LAN since the ASA isnt not involed in anyway.

The PA Internet connection naturally works as the 10.10.30.0/24 hosts are directly connected to the ASA so the above mentioned ARP will not fail on their part and traffic is forwarded just fine between the PA LAN and the Internet.

So to my understanding the solution to this problem would be to change the PA ASA "inside" subnet mask from 255.255.0.0 to 255.255.255.0.

If you are unsure of the of this change I would suggest you do it when there is low network use (so you can revernt the change) Naturally if you are on the PA LAN then you can probably access the Console connection if something were to go wrong. I cant see any configurations on the PA ASA which would imply that you configure the device remotely through the Internet.

Hope I made sense and hope this helps

Naturally ask more if needed

- Jouni

Wow, thanks for making the syn packet walkthrough so easy to understand.  I can make that change in PA easily, as I am here in PA for the week.  But having done that, what would the syn step by step be for a 10.10.10.x request for the internet?  Would I need to put something in the ASA to tell it where to look for the 10.10.10.x subnet? and would that be the PA 3900 (10.10.30.1)? or the WI 2800 (10.10.10.1)?  The 3900 already "knows" how to get to the 2800, so ... thinking aloud here.

Anyway, I will make the subnet change on the ASA, and ask AT&T to re-do their changes.  I should know if this works Monday evening, as that is the soonest that I can get both the AT&T MPLS tech and the AT&T NBF tech to set up dual tickets.

I'll let you know

Hi,

I would presume that the ASA would need a route pointing towards the PA 3900 LAN interface IP address

Something like this

route inside 10.10.10.0 255.255.255.0 10.10.30.1

I will have to say that as I dont know exactly how the PA 3900 to WI 2800 link is implemented I will have to presume how they have done it or how we would do it at our ISP where I work.

What I presume to be the case when the ASA is supposed to handle both of the LAN networks Internet connectivity is this

  • WI 2800 has an interface to both WI LAN and WI WAN.
  • The WI WAN interface leads to the ISP Core where the ISP handles the routing between these 2 locations
  • The ISP Core has a route for both the WI LAN and PA LAN and also a default route pointing towards the PA Site which eventually at PA 3900 points towards the PA ASA LAN interface IP address of 10.10.30.2
  • The PA 3900 router also has PA LAN and PA WAN link
  • The PA WAN interface leads to the ISP Core the same way as the WI WAN link above
  • The PA 3900 probably also has a separate link that handles the actual Internet connection for the PA Site (and after the change also for WI site)

What I am not sure about is how the ISP has handled the PA 3900 configuration. I mean they have had to separate the actual Internet WAN link and the WAN link heading to the WI site. Since you can really have the default route pointing towards the PA Site at the same time when you provide the default route towards the Internet. Most common way this is done would probably to use a VRF (basically creates another routing table on the router) But I would imagine this is not something you should have to worry about.

To my understanding the only thing you should do is change the PA ASA "inside" interface network mask from 255.255.0.0 -> 255.255.255.0

I am afraid I cant give you an 100% sure answer on this as I dont know the setup between the sites. And I imagine you dont have access to the PA 3900 and WI 2800 either to provide those configurations?

Am I correct to assume that currently the WI Site uses Internet directly through its ISP link as the last time you (or rather the ISP) tried to route the WI traffic through the PA Site the Internet connections failed from the WI site but the WI <-> PA traffic was fine?

- Jouni

Thanks, I will make the changes and let you know.

Yes your assumption in your last paragraph is correct.

Dennis

Was just sent this drawing of what we are trying to do.

It may help you to visualize things better

Hi,

When we look at the picture section that describes the PA network, does it actually have 2 physical routers or that single 3900 router with 2 separate GigabitEthernet interface and other interfaces to provide the WAN connectivity? (EDIT: Actually now that I look at it, it does mention the Gi0/0 port twice so I guess we are talking about 2 separate routers)

Not that it matters actually...

Its starting to seem to me that the network is built pretty much as I expected it would have been and the above matter I ask just rather clarifies the way the ISP has implemented the connectivity between the LANs and the WAN link on the PA site.

So it would seem to me that what I have suggested should be the solution to the problem with the WI Internet connectivity through PA Site and that is changing the network mask on the ASA so that the ASA doesnt think that the WI is actually directly connected network (and naturally adding the route to the ASA to tell where to find the WI LAN network). This should atleast be one problem with the setup. Naturally there might be something else, but not related to normal routing atleast if the ISP correctly specifies the default route. (I guess its now still pointing towards their own firewalls in the MPLS core network of theirs)

If the network mask change solves the problem I would keep an eye on one possible future problem on the PA site. Currently your hosts on the PA site have the router as the default gateway and this is the best choice at this point. If we presume that you were to change the ASA to be the default gateway of the PA site you would run into connectivity problems between PA and WI site (without additional ASA configurations). This would be because while the ASA would see the connections coming from the PA hosts towards WI hosts, the ASA wouldnt however see the connections/packets coming from WI hosts to PA hosts as the PA router would directly send the packets to the PA hosts wihtout forwarding the traffic to the ASA (Because the PA router already sees the PA network directly connected and therefore forwards traffic directly to hosts)

Maybe I shouldnt talk more, better to get an existing problem out of the way

Hopefully you get this thing to work on the next try Please do remember to mark a reply as the correct answe if you have found some reply to be the correct answer (after you have tested the network change the next time) and/or rate helpfull answers.

Let us know how it went.

- Jouni

Yes the PA office has two seperate AT&T routers - one for the MPLS and one for the fiber DIA

Review Cisco Networking for a $25 gift card