10-05-2010 11:18 AM
Hello all,
We have an ASA with IPSec VPN setup to Split Tunnel Internet addresses. We have one Internet Address that needs to originate from the external interface of the ASA. I've added that address to the split tunnel list and confirmed on the client that the route is to the tunnel, but I'm not able to get to that address over the VPN.
How do I get the ASA to allow this single Internet address to come in via the VPN and route back out the same interface to the Internet, and the return traffic to go back through the VPN tunnel to client.
The Internet address I need to get to is 213.92.42.118. Here's the relavent config (let me know if I left anything off):
interface GigabitEthernet0/0
nameif outside
ip address 1.1.1.1 255.255.255.0
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
name 10.80.177.0 VPN_Pool
object-group service Outbound_Ports tcp
port-object eq www
access-list nonat extended permit ip any VPN_Pool 255.255.255.0
access-list users extended permit icmp any any
access-list users extended permit tcp any any
access-list users extended permit udp any any
access-list users_splitTunnelAcl standard permit 10.0.0.0 255.0.0.0
access-list users_splitTunnelAcl standard permit 192.168.43.0 255.255.255.0
access-list users_splitTunnelAcl standard permit 192.168.40.0 255.255.255.0
access-list users_splitTunnelAcl standard permit host 213.92.42.118
access-list FWOB extended permit tcp any any object-group Outbound_Ports
global (LUXCVGASA01e) 2 1.1.1.1
nat (LUXCVGASA01i) 2 10.0.0.0 255.0.0.0
nat (LUXCVGASA01i) 0 access-list nonat
Any help is appreciated.
- Jeff
Solved! Go to Solution.
10-06-2010 08:50 AM
Hi Jeff,
Just had a chance to look through the configuration and i guess the nat configured is incorrect.
access-list nonat extended permit ip any VPN_Pool 255.255.255.0
nat (LUXCVGASA01i) 0 access-list nonat
nat (LUXCVGASA01i) 2 10.0.0.0 255.0.0.0
global (LUXCVGASA01e) 2 1.1.1.1
The access-list nonat says that ALL traffic going to the VPN pool should go un-natted. So, when you try to access the public ip through the VPN tunnel, the traffic reaches the ASA, the ASA then does a destination NAT lookup, and matches the "nat (LUXCVGASA01i) 0 access-list nonat" nat command. If the ASA finds a destination NAT translation, it will bypass route lookup and uses the destination NAT translation to determine the egress interface ( in this scenario, the egress interface is LUXCVGASA01i.
So, to resolve this issue, change the nonat acl from "any to VPN_Pool 255.255.255.0" to "inside network to the VPN_Pool 255.255.255.0.
clear xlate and re-initate the tunnel, and this should resolve the issue.
Let me know if this answers your query.
Regards,
Manisha Mandekar
10-14-2010 12:54 PM
The packet to the internet from VPN client will use the following route
route internal 0.0.0.0 0.0.0.0 10.80.80.250 tunneled
Can you check how 10.80.80.250 to route the traffic to internet?
10-05-2010 03:04 PM
Hi,
Let me see if I understand, you need to access this IP 213.92.42.118 through the VPN tunnel?
And that IP is on the outside (from the ASA perspective)?
If so...
The IP should be included in the split-tunneling and you should PAT the VPN client address when going to that address.
Please confirm if I understood your issue and we'll help you with the config.
Federico.
10-06-2010 06:44 AM
Hi Federico,
Thanks for the reply.
Yes, that's exactly right.
My issue is that I've added the IP to the split-tunnel list, and dynamically NAT'd the the VPN client address, but it doesn't work and I'm not sure why.
10-06-2010 08:47 AM
Hi Jeff,
If the VPN traffic made the U-turn on Outside interface, your nat should look like the following
nat (outside) 10
global (outside) 10 interface (or a public IP you want to NAT to)
10-06-2010 08:50 AM
Hi Jeff,
Just had a chance to look through the configuration and i guess the nat configured is incorrect.
access-list nonat extended permit ip any VPN_Pool 255.255.255.0
nat (LUXCVGASA01i) 0 access-list nonat
nat (LUXCVGASA01i) 2 10.0.0.0 255.0.0.0
global (LUXCVGASA01e) 2 1.1.1.1
The access-list nonat says that ALL traffic going to the VPN pool should go un-natted. So, when you try to access the public ip through the VPN tunnel, the traffic reaches the ASA, the ASA then does a destination NAT lookup, and matches the "nat (LUXCVGASA01i) 0 access-list nonat" nat command. If the ASA finds a destination NAT translation, it will bypass route lookup and uses the destination NAT translation to determine the egress interface ( in this scenario, the egress interface is LUXCVGASA01i.
So, to resolve this issue, change the nonat acl from "any to VPN_Pool 255.255.255.0" to "inside network to the VPN_Pool 255.255.255.0.
clear xlate and re-initate the tunnel, and this should resolve the issue.
Let me know if this answers your query.
Regards,
Manisha Mandekar
10-06-2010 08:54 AM
Also, you will need a source translation.
I see that you have a global (LUXCVGASA01e) 2 1.1.1.1.
So, you will require a nat (LUXCVGASA01e) 2
10-07-2010 10:10 PM
Hi Jeff,
Was just wondering if i have answered this query. if so, please mark this as answered.
10-08-2010 08:12 AM
Hi Manisha,
Unfortunately, this is production equipment that I have to schedule changes on, so I can't try your solution right away. I have it scheduled for next week. No worries, I'll let you know after the change whether it worked or not.
Regards,
Jeff S.
10-14-2010 10:22 AM
Hi Manisha,
The changes did not work. Below is an expanded config with the changes I made. Still not sure what the problem is, but it seems like it's not getting NAT'd when it leaves the external interface, but it looks as if it should.
Let me know if you (or anyone) sees an issue.
Regards,
Jeff S.
name 10.80.177.0 VPN_Pool
object-group network Inside_Nets
description All Inside Networks
network-object 10.0.0.0 255.0.0.0
network-object 192.168.43.0 255.255.255.0
interface GigabitEthernet0/0
nameif external
security-level 50
ip address 1.1.1.1 255.255.255.0 standby 1.1.1.3
ospf network point-to-point non-broadcast
ospf authentication null
interface GigabitEthernet0/1
nameif internal
security-level 100
ip address 10.80.185.11 255.255.255.0 standby 10.80.185.12
ospf priority 0
ospf network point-to-point non-broadcast
ospf authentication null
access-list nonat extended permit ip object-group Inside_Nets VPN_Pool 255.255.255.0
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list VPNusers extended permit tcp any any
access-list VPNusers extended permit udp any any
access-list VPNusers_splitTunnelAcl standard permit 10.0.0.0 255.0.0.0
access-list VPNusers_splitTunnelAcl standard permit 192.168.43.0 255.255.255.0
access-list VPNusers_splitTunnelAcl standard permit host 95.174.2.159
ip local pool Retail 10.80.177.7-10.80.177.150 mask 255.255.255.0
ip verify reverse-path interface external
global (LUXCVGASA01e) 2 1.1.1.1
nat (LUXCVGASA01i) 2 10.0.0.0 255.0.0.0
route external 0.0.0.0 0.0.0.0 1.1.1.254 1
route internal 0.0.0.0 0.0.0.0 10.80.80.250 tunneled
group-policy VPNusers internal
group-policy VPNusers attributes
dns-server value 10.80.179.20 10.80.224.20
vpn-simultaneous-logins 2
vpn-idle-timeout 120
vpn-filter value VPNusers
split-tunnel-policy tunnelspecified
split-tunnel-network-list value VPNusers_splitTunnelAcl
default-domain value abcdef.com
tunnel-group VPNusers type remote-access
tunnel-group VPNusers general-attributes
address-pool Retail
authentication-server-group Retail
default-group-policy VPNusers
strip-realm
strip-group
tunnel-group VPNusers ipsec-attributes
pre-shared-key *****
chain
10-14-2010 12:54 PM
The packet to the internet from VPN client will use the following route
route internal 0.0.0.0 0.0.0.0 10.80.80.250 tunneled
Can you check how 10.80.80.250 to route the traffic to internet?
10-15-2010 07:56 AM
Yudong - I think you've found it!
10.80.80.250 doesn't exist anymore. It's an old 30-bit network that was used for internal OSPF (setup and removed before my time).
I will change the default route to the next hop address (internal core), which has a default route to send traffic back to the ASA to go to the Internet. It'll take another week to complete this (isn't Change Management wonderful?), then I'll post the results.
Thank you all!
- Jeff S.
10-28-2010 12:13 PM
So this was a multi problem issue.
I did have to change my Global NAT statement to exclude internal addresses, and I did have to fix the default route for Client VPN traffic. It's working great now. Thanks to all!
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: