0

This is less likely a bug, and more likely a lack of my own understanding on routing.

I am having an asymmetric routing issue where return traffic is going out the wrong firewall. I have an explicit static route stating to go to the correct firewall's inside address, but it is ignored and travels out the default route.

 Server A      Server B
(10.0.12.7)   (10.1.12.100)
     |              |
   4500 ---------> 6500 ----------> PIX (in:10.0.11.200 out:172.16.0.162)
(10.0.11.2)    (10.0.11.1)  `-----> ASA (in:10.0.11.201 out:172.16.0.165)

Note: All the networks described here are /24

The source traffic comes from the 10.50.1.0/24 network which is connected via vpn to the ASA. If the traffic goes anywhere to the 10.1.12.0/24 network all is fine.

If the traffic goes to Server A at 10.0.12.7, the ASA reports an Asymmetric route issue.

The 4500 contains the line: ip route 10.50.1.0 255.255.255.0 10.0.11.1 The 6500 contains the line: ip route 10.50.1.0 255.255.255.0 10.0.11.201

When I ping from the 6500, using the different vlans as the source IP, this happens;

6500#ping      
Protocol [ip]: 
Target IP address: 10.50.1.11
Repeat count [5]:           
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 10.0.11.1
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.50.1.11, timeout is 2 seconds:
Packet sent with a source address of 10.0.11.1 
.....
Success rate is 0 percent (0/5)

6500#ping      
Protocol [ip]: 
Target IP address: 10.50.1.11
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 10.0.12.1
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.50.1.11, timeout is 2 seconds:
Packet sent with a source address of 10.0.12.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

As you can see it routes correctly when im sending from the vlan my servers are on. When its sent from the vlan my switches connect to each other with, it fails.

moodah
  • 43
  • 1
  • 1
  • 5
  • I should add.. The traffic selected to go over the vpn link to the 10.50.1.0/24 subnet, is 10.0.0.0/16 and 10.1.0.0/16 – moodah Jun 12 '13 at 03:42
  • "I have an explicit static route stating to go to the correct firewall's inside address, but it is ignored and travels out the default route." Which route do you think this is? Which firewall do you think is "correct"? And correct for what purpose? (And the issue is almost certainly that the ping reply isn't getting back to its source. Did you check if the ping got to its destination?) – David Schwartz Jun 12 '13 at 03:45
  • ip route 0.0.0.0 0.0.0.0 10.0.11.200 is the default route. Furthur troubleshooting however now leads me to believe that the routing is working correctly, but for some strange reason, traffic coming from 10.0.12.0/24 is simply missing the cryptomap on the ASA. I was under the belief before that the last response I was getting was from the outside address of my PIX, however its from my firewalls Next hop (aka my isp). The cryptomap is configured with the same source subnets as all my other vpn's though, so Im not sure whats happened here? Source subnets being 10.0.0.0/16 and 10.1.0.0/16 – moodah Jun 12 '13 at 04:05
  • Well. Truly my own stupidity here. I put a Global NAT/PAT that was taking priority here.. Ive adjusted it to match the user vlan specifically and the issue is fixed. Phew. Wont be telling my boss about this one. O_O – moodah Jun 12 '13 at 04:17

1 Answers1

0

When pinging through the 4500, the next hop after both firewall's was responding, not the outside interface of the PIX like I first thought.. After I realised this I checked the ASA and found that for some reason Id added a global nat that included the 10.0.0.0/16 subnet, which was picking up the traffic coming from the 4500 but not the 10.1.0.0/16 subnet.

Sorry for wasting peoples time.

moodah
  • 43
  • 1
  • 1
  • 5