Cisco ASA 5505 Backup Internet Connection Not Working

Hi there,

We have two WAN ports with two internet connections.

Primary: CMTEL
Secondary: CenturyLink

The secondary connection is not working.

I verified the connection was good via connecting directly to a laptop and entering the static WAN information. The internet worked fine doing that.

However, when I attempt to ping or use RDP on that connection when connected to the Cisco ASA 5505 it does NOT work. You can see evidence of this by the "0" hits on all of our Access Rules:
http://screencast.com/t/K1uHoFHIU


Here's what the configuration looks like:

0) Monitoring > Routes:
http://screencast.com/t/1cT4cvWg8

1) VLAN's: http://screencast.com/t/qS4yxf5L45C

2) Interfaces: http://screencast.com/t/9wNwYJkQ

3) CenturyLink Interface Config:
#1: http://screencast.com/t/nlRqhX1R
#2: http://screencast.com/t/qo9skiwxc

4) Static Routes:
http://screencast.com/t/vLmYkWNmfom

5) Service Policy Rules: http://screencast.com/t/YG4I8I8zGqQX


I am sure I am missing something extremely obvious - but I'm stumped. I really look forward to your thoughts and advice on this one.
MPATechTeamAsked:
Who is Participating?
 
asavenerCommented:
What happens if you connect a second laptop and try to get out?  I've seen where the ISP sets things up so that their device will only recognize one MAC address, at least until their device is rebooted.
0
 
MPATechTeamAuthor Commented:
Good thinking! I've tried two different laptops... And both work.

Thanks for the suggestion.
0
 
asavenerCommented:
Can you provide the output of the "show interface" command?
0
Choose an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

 
MPATechTeamAuthor Commented:
Absolutely. Here you are:

Result of the command: "show interface"

Interface Ethernet0/0 "", is up, line protocol is up
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxx.f688, MTU not set
      IP address unassigned
      37414 packets input, 2770684 bytes, 0 no buffer
      Received 15345 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      9414 switch ingress policy drops
      6380 packets output, 408320 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/1 "", is up, line protocol is up
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxx.f689, MTU not set
      IP address unassigned
      14346810 packets input, 11112636841 bytes, 0 no buffer
      Received 1387 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      3033 switch ingress policy drops
      12045682 packets output, 4367744416 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/2 "", is up, line protocol is up
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxx.f68a, MTU not set
      IP address unassigned
      15168474 packets input, 4625287078 bytes, 0 no buffer
      Received 1554057 broadcasts, 0 runts, 0 giants
      1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      689 switch ingress policy drops
      15985976 packets output, 11771008743 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/3 "", is down, line protocol is down
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex, Auto-Speed
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxx.f68b, MTU not set
      IP address unassigned
      0 packets input, 0 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      0 switch ingress policy drops
      0 packets output, 0 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/4 "", is up, line protocol is up
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxxx.f68c, MTU not set
      IP address unassigned
      543476 packets input, 43808395 bytes, 0 no buffer
      Received 19132 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      3018 switch ingress policy drops
      548697 packets output, 53877164 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/5 "", is down, line protocol is down
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex, Auto-Speed
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxxx.f68d, MTU not set
      IP address unassigned
      0 packets input, 0 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      0 switch ingress policy drops
      0 packets output, 0 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/6 "", is administratively down, line protocol is down
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex, Auto-Speed
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxx.f68e, MTU not set
      IP address unassigned
      0 packets input, 0 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      0 switch ingress policy drops
      0 packets output, 0 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Ethernet0/7 "", is administratively down, line protocol is down
  Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
      Auto-Duplex, Auto-Speed
      Input flow control is unsupported, output flow control is unsupported
      Available but not configured via nameif
      MAC address xxxxxxx.f68f, MTU not set
      IP address unassigned
      0 packets input, 0 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      0 pause input, 0 resume input
      0 L2 decode drops
      0 switch ingress policy drops
      0 packets output, 0 bytes, 0 underruns
      0 pause output, 0 resume output
      0 output errors, 0 collisions, 0 interface resets
      0 late collisions, 0 deferred
      0 rate limit drops
      0 switch egress policy drops
      0 input reset drops, 0 output reset drops
Interface Vlan1 "inside", is up, line protocol is up
  Hardware is EtherSVI, BW 100 Mbps, DLY 100 usec
      MAC address fc99.4719.f690, MTU 1500
      IP address 192.168.72.10, subnet mask 255.255.255.0
  Traffic Statistics for "inside":
      14921590 packets input, 4289712510 bytes
      15986007 packets output, 11469245453 bytes
      524199 packets dropped
      1 minute input rate 38 pkts/sec,  6112 bytes/sec
      1 minute output rate 32 pkts/sec,  5770 bytes/sec
      1 minute drop rate, 2 pkts/sec
      5 minute input rate 25 pkts/sec,  3287 bytes/sec
      5 minute output rate 21 pkts/sec,  9945 bytes/sec
      5 minute drop rate, 1 pkts/sec
Interface Vlan22 "NEP805", is up, line protocol is up
  Hardware is EtherSVI, BW 100 Mbps, DLY 100 usec
      MAC address fc99.4719.f690, MTU 1500
      IP address NEP805iface, subnet mask 255.255.255.0
  Traffic Statistics for "NEP805":
      540458 packets input, 32638886 bytes
      548697 packets output, 42189078 bytes
      17380 packets dropped
      1 minute input rate 0 pkts/sec,  28 bytes/sec
      1 minute output rate 0 pkts/sec,  16 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 0 pkts/sec,  28 bytes/sec
      5 minute output rate 0 pkts/sec,  17 bytes/sec
      5 minute drop rate, 0 pkts/sec
Interface Vlan32 "CMTEL", is up, line protocol is up
  Hardware is EtherSVI, BW 100 Mbps, DLY 100 usec
      MAC address fc99.4719.f690, MTU 1500
      IP address xxx.xxx.xxx.25, subnet mask 255.255.255.0
  Traffic Statistics for "CMTEL":
      14343786 packets input, 10844069346 bytes
      12045693 packets output, 4126802684 bytes
      254890 packets dropped
      1 minute input rate 28 pkts/sec,  3928 bytes/sec
      1 minute output rate 20 pkts/sec,  5193 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 17 pkts/sec,  8155 bytes/sec
      5 minute output rate 13 pkts/sec,  2683 bytes/sec
      5 minute drop rate, 0 pkts/sec
Interface Vlan42 "CenturyLinkNEP", is up, line protocol is up
  Hardware is EtherSVI, BW 100 Mbps, DLY 100 usec
      MAC address fc99.4719.f690, MTU 1500
      IP address xxx.xxx.xxx.222, subnet mask 255.255.255.248
  Traffic Statistics for "CenturyLinkNEP":
      28000 packets input, 1486440 bytes
      6380 packets output, 178640 bytes
      5283 packets dropped
      1 minute input rate 0 pkts/sec,  0 bytes/sec
      1 minute output rate 0 pkts/sec,  0 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 0 pkts/sec,  0 bytes/sec
      5 minute output rate 0 pkts/sec,  0 bytes/sec
      5 minute drop rate, 0 pkts/sec
0
 
MPATechTeamAuthor Commented:
I also ran an outbound ping test via the two interfaces.

The FIRST is the result of the CenturyLink connection that is NOT working.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)


This is a result of the CMTEL connection that IS working:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 30/34/40 ms
0
 
asavenerCommented:
Really looks like there isn't a significant amount of traffic on that interface:

Interface Vlan42 "CenturyLinkNEP", is up, line protocol is up
  Hardware is EtherSVI, BW 100 Mbps, DLY 100 usec
      MAC address fc99.4719.f690, MTU 1500
      IP address xxx.xxx.xxx.222, subnet mask 255.255.255.248
  Traffic Statistics for "CenturyLinkNEP":
      28000 packets input, 1486440 bytes
      6380 packets output, 178640 bytes
      5283 packets dropped
      1 minute input rate 0 pkts/sec,  0 bytes/sec
      1 minute output rate 0 pkts/sec,  0 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 0 pkts/sec,  0 bytes/sec
      5 minute output rate 0 pkts/sec,  0 bytes/sec
      5 minute drop rate, 0 pkts/sec


What physical interface is it?
0
 
MPATechTeamAuthor Commented:
It is port 0 on the physical box.

You are correct. Very little traffic. I tried pinging and rdp'ing to see if the traffic would increase. It did not.

We only use this connection for a few services... So I don't expect to see a ton of traffic. But not stagnant entirely.

Hope this makes sense.
0
 
MPATechTeamAuthor Commented:
Yes, I can do that.

When you say "emulate the router" - do you mean configure the laptop with a static IP and see if I can ping it from the ASA 5505?

We won't be on-site for awhile.

Would it be possible to try some other steps first? I agree this is a great suggestion, though.
0
 
asavenerCommented:
Can you connect a laptop to that interface on the ASA, and emulate the router?

This is mainly to see if the interface is working, that auto negotiate works, etc.
0
 
asavenerCommented:
Yes, configure the laptop with the static IP and subnet of the router.

Might want wireshark on the laptop, so that you can see the traffic in and out of the interface.



Other options for troubleshooting are:  1) Traffic tracer to see if there's some weird rule blocking the traffic, 2) packet capture on that particular interface, which you can import into wireshark.
0
 
MPATechTeamAuthor Commented:
Got it - Thanks.

Would you suggest just deleting the interface and re-adding it? That would kill all associated rules, right?

1) Traffic tracer to see if there's some weird rule blocking the traffic
-- Is this something I can do remotely?
0
 
asavenerCommented:
Sorry, it's called "packet tracer."  You can run it from the ASDM GUI interface.  Basically, you put in the traffic info (source IP and port, destination IP and port, ingress interface, etc.) and then it compares the traffic to each of your rules and spits out whether the traffic is permitted or denied, and the reason why.

http://www.techrepublic.com/blog/data-center/cisco-asa-packet-trace-your-firewall-debug-friend/1482/#.
0
 
MPATechTeamAuthor Commented:
Okay - DONE!

I don't see anything abnormal... do you?

http://screencast.com/t/o52fS7UZs4
0
 
MPATechTeamAuthor Commented:
Okay, this is interesting.

After I ran that test... I DID see a HIT on the firewall rule. This is the first one I've seen in what feels like centuries.

Check it out: http://screencast.com/t/OMHj82xb

So, during the test, everything came through A-OK.
0
 
asavenerCommented:
That all looks right to me....

I've seen weird problems like this get cleared up after a reboot.  No promises, though.
0
 
MPATechTeamAuthor Commented:
Hi there,

Unfortunately, we have tried a reboot :(

Any other ideas?

I could delete and re-add the interface. Hate to do that though if you are 99% that won't fix it.
0
 
asavenerCommented:
What does your routing table look like?
0
 
asavenerCommented:
I honestly don't know if deleting and readding the interface will help.  It's worth a shot, I suppose, but I'm currently leaning more toward layer 1 issues.
0
 
Marius GunnerudSenior Systems EngineerCommented:
The problem is that the ASA is not a router.  You have two default routes configured, but only one of them will be active at any given time (the route with the lower metric).  So what you are seeing is perfectly normal for the ASA.  You will not be able to use both the links for internet use at the same time.
0
 
asavenerCommented:
Actually, you can use both interfaces, but not for all destinations.  The routing table determines which interface the ASA uses.

And based on the screen capture he posted, there is only one default route.
0
 
MPATechTeamAuthor Commented:
@MAG03,

Actually, yes you can. In the context I'm speaking of, at least.

You are correct that it does not do load balancing / outbound traffic. BUT, you can definitely access services through a specific connection.

I know this will work because in the past it was configured and working this way just fine. For example, I used RDP & 443 Exchange traffic (inbound connections) via a secondary interface.

I understand that by adjusting the Metric I can control which connection is the ACTIVE/PRIMARY internet connection. This doesn't mean the second connection quits working though - it's just not active as the default route.

Hopefully this is clear. I understand I can't load balance outbound traffic at the same time.

@ASAVENGER
What route table screen or command are you looking for?


I look forward to further thoughts & guidance.
0
 
MPATechTeamAuthor Commented:
Sorry @asavener

Didn't mean to double up on your post. I see you already corrected @MAG03.
0
 
MPATechTeamAuthor Commented:
Result of the command: "show route"

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is CMTELGateway to network 0.0.0.0

C    192.168.72.0 255.255.255.0 is directly connected, inside
C    ***.***.***.0 255.255.255.0 is directly connected, CMTEL
C    ********* 255.255.255.0 is directly connected, NEP805
S    ********* 255.255.255.0 [1/0] via NEPDevGW, NEP805
C    ***.***.***.216 255.255.255.248 is directly connected, CenturyLinkNEP
S*   0.0.0.0 0.0.0.0 [1/0] via CMTELGateway, CMTEL

What is strange to me, is NOWHERE do I have ".216" entered.
My Gateway ends in: .217
My Primary IP ends in .222

I do not know how it is pulling the .216 address.
0
 
Marius GunnerudSenior Systems EngineerCommented:
Yes, you are correct that you can use the second interface for certain traffic, but in this case you can not have a default route configured for it, you will need a more specific route configured pointing out that interface.

There is a second default route configure as per the screenshot in the original post:
http://screencast.com/t/vLmYkWNmfom

But it is also possible to keep it the way you have it, but you would need to enable TCP bypass and do some creating policy NATing.  Though this I would not recommend doing.
0
 
asavenerCommented:
There is a second default route configure as per the screenshot in the original post:
http://screencast.com/t/vLmYkWNmfom
That's the proper configuration for failover - two default routes with different metrics.  Only one default route is active, however.

See this screen shot of the active routes, or the routing table posted above:
http://screencast.com/t/1cT4cvWg8
0
 
asavenerCommented:

C    ***.***.***.216 255.255.255.248 is directly connected, CenturyLinkNEP

What is strange to me, is NOWHERE do I have ".216" entered.

That's correct for a subnet mask of 255.255.255.248. A subnet mask of that length breaks up the class C subnet into 32 subnets with eight addresses each.  216 is the base of the subnet, and is not usable.  223 is the broadcast of the subnet, and is not usable.  The other six addresses (217-222) are usable addresses.

A configured address with a last octet of 217 and a subnet mask of 255.255.255.248 is implicitly part of the x.x.x.216 255.255.255.248 subnet.
0
 
asavenerCommented:
So, what's the next step you're going to try?  The available options I see are 1) emulating the CenturyLinkNEP gateway with a different device, 2) deleting and re-adding the interface, and 3) performing a packet capture on the CenturyLinkNEP interface.
0
 
MPATechTeamAuthor Commented:
Thanks for the follow up.

Last night I tried deleting and re-adding. No cigar.

I was thinking I would switch it to a different port now? Seems like that is really all that's left?
0
 
asavenerCommented:
You can also replace cabling.
0
 
MPATechTeamAuthor Commented:
I've unfortunately tried the cabling replacement already :s

So we are left with only the port, I think?
0
 
asavenerCommented:
That and/or packet capture/analysis.
0
 
MPATechTeamAuthor Commented:
Switched it to a different interface. Still no luck :(

What else could it possibly be? I'm not really sure what a packet capture could tell us...given we know the connection does work.

Any brilliant thoughts? Thanks again.
0
 
asavenerCommented:
Try connecting another device to the edge router, and then see if you can hit it from the outside.  Maybe the ISP is blocking the traffic.

Other than that, a call to the service provider and see if they'll help you troubleshoot.
0
 
MPATechTeamAuthor Commented:
I see. You think the ISP may be blocking our Mac Address of the router? I could see that.
0
 
asavenerCommented:
Or they may have a firewall enabled that's blocking all inbound traffic.

Another test might be to add a route on the ASA just for the IP address you're testing from.
0
 
MPATechTeamAuthor Commented:
I actually tested (when hooked up to a laptop) RDPing into it.

I verified that I could do that. Thus that tells me centurylink isn't blocking anything.

I can try exclusively allowing the ip I'm testing rdp from if you think that could work.
0
 
asavenerCommented:
I think it could possibly be the problem.

You might just test to see if the policy drops counter increments when you attempt an RDP connection.

I know that you can enable a feature on IOS routers to drop traffic if the source address does not match any entries on the routing table for the ingress interface.  ASA may do that by default.  ASAs do a lot of counterintuitive things because they're first and foremost a security device and not a router.
0
 
MPATechTeamAuthor Commented:
Can you clarity if you're meaning to are a more specific access rule?
0
 
asavenerCommented:
No, I'm talking about routes.

If you have a laptop on the internet, and your public ip is 4.2.2.2, then you should add a route on the ASA going out the backup interface.



route CenturyLinkNEP 4.2.2.2 255.255.255.255 CenturyLink-NEP-Gateway
0
 
MPATechTeamAuthor Commented:
Thank you!

Dumb question: Where can I view routes via the ASDM?

Here's a test scenario example:

Public IP from Remote Location > CenturyLink Public IP > ASA 5505 > Access Rule configured  for RDP on port 3389.

Thoughts?
0
 
asavenerCommented:
0
 
MPATechTeamAuthor Commented:
Sorry - I should have known what you meant.

I added it. See this screenshot:
http://screencast.com/t/2smpKCoqkkIp

Unfortunately - still not cigar.

The more I thought about the Mac Address Blocked Thought:
Since this is a DSL modem based connection - wouldn't the mac address of the modem get blocked, not the ASA 5505 Firewall?

Thanks again.
0
 
MPATechTeamAuthor Commented:
Okay, now THIS is interesting.

I CAN ping the CenturyLink GATEWAY via the Cisco ASA 5505.

I can NOT ping Google (DNS Server) via it though.

That tells me the CenturyLink connection is reaching the first hop, the gateway.

Check out this screenshot (first, tried to ping Google DNS, second, pinged CenturyLink Gateway)

http://screencast.com/t/VLlenmPPT0k
0
 
MPATechTeamAuthor Commented:
I found this article online:
http://community.spiceworks.com/topic/320787-cisco-asa-5505-configuration-issue

Specifically, I found this comment:

i just ran into a similar problem on my ISR hooking up a second route. I had to creat a routemap and set the next hop to the new connections interface then apply the route map to a test vlan so that i could do it during operating hours. I thaink Dashrender is right. if you disable the timewarner it might work.

my problem was that when you ping something it uses the route table even if you source the ping from that new interface so it tries to go back out the initial interface. there is a way to set the local route for a given ip (in this case your gateway for windstream) to force it to use the new interface. on my ISR i had to put a static route in.

ip route (windstream gateway IP) 255.255.255.255 E0/1 permanent

i dont think the route commands are the same in the ASA but you can poke around and figure it out. that will at least let you ping.

do you see the windstream IP as directly connected when you do a "sho ip route"?


-------------

This makes a fair amount of success given my testing.

I am not clear on the Route Map portion. Looking at this document:
http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/asdm63/configuration_guide/config/route_maps.html#wp1121595

My ASDM 6.2 interface does not have a section for Route Maps, on Static Routes.

Thoughts?
0
 
asavenerCommented:
Yes, the egress interface will always be based on the route table, even if the source IP is the other interface.  You can likely ping the gateway because it's a locally-connected subnet, which means it takes precedence over the default route.
0
 
MPATechTeamAuthor Commented:
Okay -

But, there is no reason I shouldn't be able to ping Google from the ASA using the CenturyLink interface, right?

Does this rule out that the Mac Address is being blocked by CenturyLink?

Can you advise next steps based on this new information?
0
 
MPATechTeamAuthor Commented:
What about one of these options? Could they be relevant to the issue?

http://screencast.com/t/0icxuS6jKPS
0
 
MPATechTeamAuthor Commented:
License Information: http://screencast.com/t/DQJLR7dbI

I also checked out the ACL Manager. Here's a screenshot of what that looks like:
http://screencast.com/t/3LonttlmZ3
0
 
asavenerCommented:
But, there is no reason I shouldn't be able to ping Google from the ASA using the CenturyLink interface, right?
Well, your route to google doesn't go out the CenturyLink interface; it goes out your primary interface.

This goes back to adding routes that go out your backup interface.
0
 
MPATechTeamAuthor Commented:
I understand --
But in the past i never had to add an individual route for each outbound connection.

Specifically, because in the testing I am specifying the CenturyLink connection when performing the test.

None the less - I may just be misunderstanding. You may mean that I can't initiate an egress connection and my testing here is totally irrelevant.

If that's the case, then I need to go back to the theory of testing INGRESS connections on the CenturyLink connection.

Any thoughts?
0
 
MPATechTeamAuthor Commented:
Alright, you slapped me around pretty good there. I added the Static Route, and now I can ping outbound.

http://screencast.com/t/wsOnvyeI

This test was useful because it fully confirms that the internet DOES work.


So, now I need to figure out why I can't establish any inbound connections to the connection.

I then added THIS rule:
http://screencast.com/t/rclTK6aBpo
(This is the PUBLIC IP of the office i"m testing from)

When I tried to RDP in -- IT WORKED!

But, I need to permit traffic from ANY IP to access this connection if they hit it via the connection's IP.

I used to be able to do this -- I'm not sure why it quit working. Any ideas?
0
 
asavenerCommented:
OK.

For testing ingress, I still recommend connecting the CenturyLink connection to a different device with the same address as your CenturyLink gateway.
0
 
MPATechTeamAuthor Commented:
Okay, this is insane.

I REMOVED what I just added:
http://screencast.com/t/rclTK6aBpo

And RDP still works. Ping, oddly enough, quit working as soon as I killed it.

I'm still testing. Just wanted to update you.
0
 
asavenerCommented:
I think the NAT translation will remain active until you issue a clear xlate command.

I could be wrong, though.
0
 
MPATechTeamAuthor Commented:
Gotchya. So if that's the case --
How can I make it so any ingress IP can access the CenturyLink connection, like I was able to previously?
0
 
MPATechTeamAuthor Commented:
I think it's actually working... Just tested from my cell phone. I am at a complete loss here....
0
 
asavenerCommented:
OK, if you're trying to segment the traffic based on traffic type, then you're not going to be able to do it on the ASA.

What you're describing requires policy-based routing (PBR), which as of 8.4 the ASA is not capable of.  I haven't researched more recent versions, but I don't believe it's a feature that has been incorporated.

What you need is a router capable of performing PBR.  Then you just have the one "outside" interface on the ASA that connects to the router, and the router handles the traffic management to load balance between the ISPs.
0
 
asavenerCommented:
Try executing a clear xlate or rebooting the ASA, and I bet it will stop working.

At least we've eliminated cabling, ARPs, and vendor firewalls from what's going on.
0
 
MPATechTeamAuthor Commented:
Hi there,

All I was after was to be able to connect via a specific interface IP - ingress initiated traffic only.

Unbelievably, my config looks exactly like it did when we started, but it DOES now work exactly like I expect.

It APPEARS that the solution was:
ADD THIS RULE - Then REMOVE it:
http://screencast.com/t/rclTK6aBpo
0
 
MPATechTeamAuthor Commented:
Since I'm able to connect via my Cell Phone's internet connection (different PUBLIC IP) doesn't this indicate it is infact working A-OKAY?

I never specifically permitted my cell phone's public IP - only the office IP I was testing from.

You've slapped me around once, so feel free to do it again if I'm jumping to the wrong conclusions!
0
 
asavenerCommented:
Not trying to slap you around; I'm just suspicious of stuff that just starts working....

If it continues working after a reboot, then you will have convinced me.
0
 
MPATechTeamAuthor Commented:
I agree 1000%.

But, I'm not going to reboot it now since I'm not on-site.


But, just to vindicate my assumption:
Since I'm able to connect via my Cell Phone's internet connection (different PUBLIC IP) doesn't this indicate it is infact working A-OKAY?

I never specifically permitted my cell phone's public IP - only the office IP I was testing from.



Am I reaching a reasonable conclusion here?
0
 
asavenerCommented:
I don't think I have enough information to provide a meaningful reply.
0
 
MPATechTeamAuthor Commented:
Okay, we will wait a little bit and make sure things keep working. if they do, I'll accept your answer and award you the points.

Thank you for all of your help!
0
 
asavenerCommented:
Happy to help.  Have a great day.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.