How to add an external IP address to a split tunnel?

[kettmanng]

Hi,

I have set up the VPN access on my ASA box such that clients are using a split tunnel so that only the traffic to our internal network goes through the tunnel. Now I need to add an external IP address to that tunnel. Is that possible, and if so, how can I achieve that? Just adding the address to the tunneled network list doesn't work; if I do that, the client cannot connect to the external address at all.

Can anyone help?

Cheers, Georg.

[Jouni Forss · Accepted solution]

Hi,

Would need to see some configurations.

Typically inbound traffic from a VPN bypasses interface ACL. If you have nondefault setting you might have to allow traffic to the server from the VPN Pool network/subnet. Unless ofcourse the server already has a rule allowing traffic from "any" source address.

Also one likely problem might be your NAT configuration.

Is the local IP address of the server holding the public IP address included in the current NAT0 configurations for the VPN Connection? If so then that will probably cause problems for the connections towards its public IP address. The traffic might be dropped because of a NAT RPF check which essentially checks the NAT that matches for the traffic in the other direction.

So confirm the above things or share the configurations so we can do it.

To my understanding adding the IP address to the Split Tunnel should naturally be required also.

EDIT: Post number 6000

- Jouni

[kettmanng]

Hi Jouni,

thanks for your reply. Part of the problem is that I am not a really experienced ASA/network admin, so I not really sure what kind of information you need.

NAT and static routes:

nat (inside,outside) source static NETWORK_OBJ_x.y.232.0_21 NETWORK_OBJ_x.y.232.0_21 destination static NETWORK_OBJ_x.y.232.224_27 NETWORK_OBJ_x.y.232.224_27 no-proxy-arp route-lookup

!

object network obj_any

nat (inside,outside) dynamic interface

route outside 0.0.0.0 0.0.0.0 x.y.248.254 1

route inside x.y.31.205 255.255.255.255 x.y.239.254 1

x.y.31.205 is the external IP address, our internal network is x.y.232.0/21, gateway x.y.239.254, the network for the external interface is x.y.248.0/24, gateway x.y.248.254.

Oh, and I forget the error message on the ASA:

Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:x.y.232.235/49857(LOCAL\username) dst inside:x.y.31.205/80 denied due to NAT reverse path failure

Cheers, Georg.

[Jouni Forss]

Hi,

The log message you included would seem to indicate that the problem is indeed the NAT configured for this host behind your "inside" interface. While the connections from the external network work fine, the traffic from the VPN pool matches 2 different "nat" configuration and the traffic gets dropped.

What we could do to determine the problem would be to test the ASA configurations with the "packet-tracer" command WHEN a VPN Client user is connected.

You could use a command

packet-tracer input inside tcp x.x.31.205 12345 80

Or perhaps

packet-tracer input outside tcp 12345 x.x.31.205 80

You could then share the output here (while removing the public IP address atleast partially like so far) and we could probably tell what the problem is and what configuration is needed to correct the situation.

I am kinda wondering if you have a public IP address on a server directly on the LAN network then I would assume that you have NAT0 configured for it so it would be visible directly to the external networks with its own public IP address (directly configured on the server NIC) but this situation would suggest that it is actually NATed/PATed before heading to the external network. Or it seems so.

- Jouni

[kettmanng]

Hi,

I deleted the second NAT rule, and now it seems to work. Thanks for your help!

Georg.

[Jouni Forss]

Hi,

Glad to hear you managed to solve the problem.

What NAT configuration did you actually remove?

Hopefully nothing that would affect other hosts

- Jouni

[kettmanng]

I removed this one:

object network obj_any

nat (inside,outside) dynamic interface

I did this on my backup box (and actually noticed that the primary ASA did not have this rule at all), and I've asked people to test it...

Cheers, Georg.