L2VPN with ASA5540 and asymetric routing

ijdasjdiasjdoi · ‎08-10-2012

Hi,

we are using two ASA5540 (8.4(4)) as a load-balanced VPN-Cluster. Primarily the cluster is used for layer-2 customer VPN using Cisco VPN-Client IPSEC.

Now the followeing constellation applies:

ASAs have a outside interface each that is used for the default-route (Port-channel1).

Manageement interface is used for load-balancing/heartbeat (Management0/0

A trunk port for every customer VLAN (Port-channel2). Especially Port-channel2.220

(For security reasons I had to scamble the IPs. We have two Class B subnets: 936.927.0.0/16 and 930.934.0.0/16)

There profile allows customers to establish a VPN-Connection to get an IP from 936.927.83.0/24. Creating the connection is working as expected.

The Problem:

When a client initiates a TCP-Connection over his VPN-connection to any address that is external to 936.927.83.0/24, the packet is routed over ASA's default-route and outside-interface (Po1).

Now the SYN-ACK packet returns to our backbone and is correctly routed to the gateway of 936.927.83.1 (not ASA) and reaches ASA's inside interface Po2.220. At that point is see both ASAs dropping those packets and the tcp handshake breaks.

Actually this is a case of asymetrical routing, but i cannot change the routing on the backbone-routers.

EDIT1:

The log message is:

Deny TCP (no connection) from 173.194.35.152/443 to 936.927.83.63/50008 flags SYN ACK  on interface inside220

Ping and traceroute work on all destinations. UDP e.g. DNS works either.

Thanks for help and suggestions.

The config of the first ASA:

ASA Version 8.4(4)

!

hostname c5540-vpn-1

interface GigabitEthernet0/0

description n7k-ww10-trsh-3 A

channel-group 1 mode active

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/1

description n7k-ww10-trsh-3 B

channel-group 1 mode active

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/2

description n7k-ww10-3 A

channel-group 2 mode active

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/3

description n7k-ww10-3 B

channel-group 2 mode active

no nameif

no security-level

no ip address

!

interface Management0/0

description c4k-ww10-1

nameif management

security-level 100

ip address 930.934.6.161 255.255.255.0

!

interface Port-channel1

description n7k-ww10-trsh-3

nameif outside

security-level 0

ip address 930.934.5.238 255.255.255.224

!

interface Port-channel2

description n7k-ww10-3

nameif inside

security-level 100

no ip address

!

interface Port-channel2.220

description HSZ

vlan 220

nameif inside220

security-level 100

ip address 936.927.83.87 255.255.255.0

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

access-list dhiparis_network extended permit ip any 930.934.215.208 255.255.255.240 ! ignore this, not part of the problem

access-list 101 extended permit ip any any

access-list rfc1918 standard permit 10.0.0.0 255.0.0.0

access-list rfc1918 standard permit 172.16.0.0 255.240.0.0

access-list rfc1918 standard permit 192.168.0.0 255.255.0.0

mtu outside 1500

mtu inside 1500

mtu management 1500

mtu inside220 1500

ip local pool hszpool 936.927.83.63-936.927.83.86 mask 255.255.255.0

icmp unreachable rate-limit 1 burst-size 1

icmp permit any outside

icmp permit any echo-reply outside

icmp permit any echo outside

icmp permit any time-exceeded outside

icmp permit any unreachable outside

icmp permit any inside

icmp permit any management

icmp permit any inside220

icmp permit any echo inside220

icmp permit any echo-reply inside220

access-group 101 in interface outside

access-group 101 out interface outside

! Default route

route outside 0.0.0.0 0.0.0.0 930.934.5.254 1

dynamic-access-policy-record DfltAccessPolicy

aaa-server radius-hsz protocol radius

max-failed-attempts 2

aaa-server radius-hsz (outside) host 930.934.5.101

timeout 4

key *****

authentication-port 1889

accounting-port 1813

aaa-server radius-hsz (outside) host 930.934.5.103

timeout 4

key *****

authentication-port 1889

accounting-port 1813

crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes esp-sha-hmac

crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 3600

crypto ipsec security-association lifetime kilobytes 2147483647

crypto ipsec df-bit clear-df outside

crypto dynamic-map outside_dyn_map 500 set ikev1 transform-set ESP-3DES-SHA

crypto dynamic-map outside_dyn_map 500 set security-association lifetime seconds 86400

crypto map outside_map 10 match address dhiparis_network

crypto map outside_map 10 set pfs

crypto map outside_map 10 set peer 984.914.922.953 ! ignore this

crypto map outside_map 10 set ikev1 transform-set ESP-3DES-MD5

crypto map outside_map 10 set security-association lifetime seconds 86400

crypto map outside_map 10 set nat-t-disable

crypto map outside_map 500 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map interface outside

crypto isakmp identity hostname

crypto isakmp nat-traversal 3600

crypto isakmp disconnect-notify

crypto ikev1 enable outside

crypto ikev1 policy 1

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

crypto ikev1 policy 3

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

client-update enable

vpn load-balancing

priority 9

interface lbprivate management

cluster key *****

cluster ip address 930.934.5.237

participate

group-policy HSZ internal

group-policy HSZ attributes

dns-server value 930.934.4.1 930.934.5.1

vpn-idle-timeout 240

vpn-session-timeout none

password-storage enable

ip-comp disable

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy excludespecified

split-tunnel-network-list value rfc1918

client-firewall none

tunnel-group HSZ type remote-access

tunnel-group HSZ general-attributes

address-pool hszpool

authentication-server-group radius-hsz

accounting-server-group radius-hsz

default-group-policy HSZ

tunnel-group HSZ ipsec-attributes

ikev1 pre-shared-key *****

Karsten Iwen · ‎08-10-2012

Do I understand you right? Your client connects to ASA2 and gets an IP address from the local pool but the answer is routed to ASA1?

Do you have routing in your backbone that the ASA1-pool is always rooted to ASA1 and the ASA2-pool is always routed to ASA2? If the pools are local to each ASA it can be implemented with static routing. If you have clients that get their IP from a central server (AAA or DHCP) then you have to work with reverse-route-injection.

If that's not the problem, just draw a picture.

--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

ijdasjdiasjdoi · ‎08-10-2012

The load-balancing is not the problem. Maybe just sick with there's just one ASA.

Here's a simple topology with the ASA, backbone and customer network:

When the VPN-Client sends packet to e.g. 173.194.35.159 (google.de), ASA routes that packet according to its default route, that is via outside interface.

.83.0/24 is being routed on Gateway .83.1. So flows to that network are not routed into the ASA (outside interface); but are being Layer-2 forwarded to its inside220 interface.

When the VPN-Client sends packets destined to .83.0/24 everything works perfectly, because ASA saw the SYN packet on inside220 and receives the SYN-ACK on it also.

Hope that helps to understand the problem.

Karsten Iwen · ‎08-10-2012

That can be fixed with the "tunneled default-route":

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/route_static.html#wp1121567

--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

ijdasjdiasjdoi · ‎08-13-2012

Thanks for your support.

This may be a solution if I just had one customer on this ASA.

But actually we are consolidating VPN-Routers onto the ASA-Cluster, so I cannot just set one default tunneled route.

Is it possible to let ASA route traffic based on SRC-Address or some kind of ACLs?

Or have the ASA accept packets on inside interfaces appropriately?

Edit:

UDP and ICMP work correctly. It's just TCP that the ASA is dropping.

Karsten Iwen · ‎08-13-2012

Is it possible to let ASA route traffic based on SRC-Address or some kind of ACLs?

No, the ASA doesn't support any policy-based routing.

Or have the ASA accept packets on inside interfaces appropriately?

Only if you disable state-bypass. But that shouldn't be the solution. A redesign is probably the better solution.

UDP and ICMP work correctly. It's just TCP that the ASA is dropping.

UDP/TCP can work with the right ACLs, but TCP won't work that way.

--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

ijdasjdiasjdoi · ‎08-13-2012

What do you mean by "A redesign is probably the better solution"?

Is this scenario not possible with ASAs?

I know that Cisco's ISR like 2900-series do not have any problems with asymetric routing in this constellation. ASAs differ from those a lot.

Karsten Iwen · ‎08-13-2012

I think the disign has some flaws, at least if an ASA is involved ... And the ASA is not a subtituion for a router. If you want to use the ASA only as an VPN-gateway and not as a firewall it really could be a solution to change the ASA against a router and connect the ASA on a stick with just one interface. Then you have all routing-control an the connected router.

--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

ijdasjdiasjdoi · ‎08-13-2012

Thanks for your suggestion.

But I don't see any change in my design that would help in this situation.

The ASA needs an (sub)interface in every vlan, that should be accessible via a Layer2-VPN. Otherwise the ASA wouls not even receive any return-packets, as they are routed to the gateway (which is not the ASA).

Actually the ASA does get the appropriate answer-packet, simply on its inside-interface and not on its outside, where it sent the packet from (this is the asymmetry).

Anyway all ASAs are attached to a Nexus7000, that's whre I can make major changes to the routing. But that won't help as the return-packet is just switched to the ASA.