cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5104
Views
0
Helpful
8
Replies

SSL vpn and routing problem

Malette40
Level 1
Level 1

Hi all,

I have a quite strange VPN architecture included and i have some problems that i am not able to resolve:

- I use the ssl vpn gateway to allocate internal IP adresses of the local network described in the diagramm (network 8.8.2.0 or 8.8.3.0 depending on the tunnel-group.

- The purpose is for vpn clients to gain directly access to the internal network.

This works fine if there are strictly internal communications within the network. However recently we installed an application that needs access to the two networks. No problem i thought, but i was wrong, there seems to be a routing problem inherent to the architecture in place.

Let me explain the problem:

-When i am accessing to the vpn, for example i will be given the 8.8.3.5 ip adress.

- Im am running the application which needs to open a page on the web server located at 8.8.2.120

- the asa receive my tcp syn datagram and forward it directly to the directly connected interface fa0/1 (based on the routing table)

- the web server sends back the response but sends it on its default gateway which is the cisco 6509.

- The 6509 sends it on its svi vlan 2000

- and finaly the ASA receives it on its fa0/2 interface but seems drops it since it opened a tcp connection on fa0/1 and receives the response on fa0/2.

What i would like is for tunneled traffic to bypass connected routes and forward it to a tunnel default gateway. This would ensure that the path for the request and the response would be the same.

I would like to know if there are debug commands for routing decisions to validate my theory ?

Do you know of any answer to resolve this problem ?

Many thanks for your help.

3 Accepted Solutions

Accepted Solutions

When setting up TCP state bypass always think "which way is the SYN packet coming from?".

Routing failed messages have always source and destination, are you sure copied the whole message?

BTW, instead of giving SSL clients addresses assigned to vlan2000? Why not give them a separate subnet and route it back through proper interface?

I'd also want to check your config and routing table :-)

Marcin

View solution in original post

Cant we assign a specfic route on the server itself that states that route to the SSL VPN subnets exists through the asa f0/1 rather making the server use the Default route that sends it to the Cisco 6509.

manish

View solution in original post

That or a tunneled route could potentially be a solution.

Marcin

View solution in original post

8 Replies 8

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Well first of all I'm not sure why not correct the routing....  ;-)

That being said TCP state bypass is what you're looking for as a workaround:

http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/conns_connlimits.html#wp1089825

Marcin

Thanks for your help !

I did some tests on your workaround, but i can't apply this command and i don't quite understand how to apply it. The cisco doc is a little confusing since there is two ASA to config, and it is not precised if on this example, the command need to be configured on ASA 1 or on ASA 2.

On a first thought, it was logical for me to apply tcp state bypass to the traffic return (i.e 8.8.2.120 to 8.8.3.5) but it seems to not work correctly. What i did:


access-list tcp_bypass extended permit tcp 8.8.2.0 255.255.255.0 8.8.3.0 255.255.255.0
hostname(config)# class-map tcp_bypass
hostname(config-cmap)# description "TCP traffic that bypasses stateful firewall"
hostname(config-cmap)# match access-list tcp_bypass

hostname(config-cmap)# policy-map tcp_bypass_policy
hostname(config-pmap)# class tcp_bypass
hostname(config-pmap-c)# set connection advanced-options tcp-state-bypass

hostname(config-pmap-c)# service-policy tcp_bypass_policy outside

A quick check into the log told me that this was working a little bit, we found an entry for the building of the tcp state bypass entry,

but after we found this type of message:

"Routing failed to locate next hop for inside2:8.8.2.120" and i agree with this message, but why the asa is trying to send a response to the inside2 interface (which corresponds to fa0/2) ?

With tcpdump on the server, i found that the syn tcp datagram was received but not the syn ack...

Then, I was desperate and tried to include this class-map and an other class-map (with the acl reversed) into a single policy-map and applied it to the 3 interfaces.

The result was not bad considering my desperate attempt...

With wireshark, i found that the syn and syn/ack was ok, but not the last ack.


In conclusion, i am not sure at how i should apply the tcp state bypass.

- Which acl does it need to match ?

Only the traffic where it that should be disabled (i.e from the server to my adress) ?

- On which interfaces does it need to be active ?

I would say that this need to be active on the inside2 interface but i am not sure.

Thanks for your help.

When setting up TCP state bypass always think "which way is the SYN packet coming from?".

Routing failed messages have always source and destination, are you sure copied the whole message?

BTW, instead of giving SSL clients addresses assigned to vlan2000? Why not give them a separate subnet and route it back through proper interface?

I'd also want to check your config and routing table :-)

Marcin

Cant we assign a specfic route on the server itself that states that route to the SSL VPN subnets exists through the asa f0/1 rather making the server use the Default route that sends it to the Cisco 6509.

manish

That or a tunneled route could potentially be a solution.

Marcin

Yes in fact, i was relying on my memory to rewrite the log message, so it was only a part of this message.

A tunneled route did the job, i wrote:

access-list tcp_bypass2 extended permit tcp 8.8.2.0 255.255.255.0 8.8.3.0 255.255.255.0

access-list tcp_bypass extended permit tcp 8.8.3.0 255.255.255.0 8.8.2.0 255.255.255.0

hostname(config)# class-map tcp_bypass

hostname(config-cmap)# match access-list tcp_bypass

hostname(config)# class-map tcp_bypass2

hostname(config-cmap)# match access-list tcp_bypass2

hostname(config-cmap)# policy-map tcp_bypass_policy

hostname(config-pmap)# class tcp_bypass

hostname(config-pmap-c)# set connection advanced-options tcp-state-bypass

hostname(config-cmap)# policy-map tcp_bypass_policy2

hostname(config-pmap)# class tcp_bypass2

hostname(config-pmap-c)# set connection advanced-options tcp-state-bypass

hostname(config-pmap-c)# service-policy tcp_bypass_policy outside

hostname(config-pmap-c)# service-policy tcp_bypass_policy2 inside2

hostname(config)# route inside2 0.0.0.0 0.0.0.0 8.8.3.254 tunneled

And that worked.

So many thanks to you two for your help.

As a side note, i cannot use a proper adressing scheme for the vpn client pool because i dont have the control of the cisco 6509, so for us the best solution was to have a direct access to internal network.

Cool, glad it's working :-)

I think we can all agree it's not a very neat workaroud but at least a working one.

I wonder if you could squeeze those two ACLs into one ACL and one class-map and apply it under global policy instead of per-interface one.

Would make it a bit more readable. But hey if it's working I understand you might not want to touch it

Marcin

Well, yeah i agree for this workaround but with this type of architecture (quite a odd one in fact), this is the best that you two helped us to find.

For the single acl and the single class map, i will try this tomorrow if i have some free time (its 11' PM over here...)

Anyway many thanks for your help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: