cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
837
Views
5
Helpful
12
Replies

VPN Tunnel unable to pass traffic

c.f.ryback
Level 1
Level 1

I think that I have a "forest and tree" issue here.

I have an ASA 5510, IOS 7.0(5) running the ADSM 5.0. Have successfuly configured an VPN tunnel using a Windows 2003 Server IAS for Authorisation for login.

That works successfully, but I can't pass any traffic down the tunnel once it is nailed up. I'm sure that it is a basic NAT or ACL that I am missing. The only traffic that I want on the VPN is TCP port 3389 so clients (using the Cisco VPN Client 4.8.X) can connect to our 2003 Terminal server.

I have configured a VPN Pool address range of 172.16.0.1 - 172.16.0.51/24. My test client picks up the IP address OK, but then uses the same IP as its gateway. Not sure if that is the problem, as I would have thought that the client would use the VPN interface address as a gateway...Either way, once the tunnel is established, I cannot ping or establish a connection to our TS Server.

Below are the Route and NAT rules that are currently in place. Keep in mind that we have 2 DSL lines incoming, one for normal net traffice (yet to go live) and one for VPN traffic. The device is called Gatling-06, and I have four interfaces on it enabled - GCC_LAN (connected to our LAN), GCC_WAN (for normal Internet Traffic), GCC_VPN (for our VPN Traffic) and the Management interface.

Route:

S 0.0.0.0 0.0.0.0 [1/0] via 147.109.239.XXX, Gatling_GCC_WAN

S 10.10.0.0 255.255.255.255 [1/0] via 147.109.139.XXX, Gatling_VPN

C 10.10.0.0 255.255.254.0 is directly connected, Gatling_GCC_LAN

C 147.109.239.XXX 255.255.255.240 is directly connected, Gatling_GCC_WAN

C 147.109.253.XXX 255.255.255.248 is directly connected, Gatling_VPN

NAT config, in attachment.

I'm sure that I am missing something pretty basic, but haven't been able to see exactly what it is - yet! The other thing I have noticed is that the ASA is rejecting NetBIOS traffic, I don't really want to allow client NetBIOS traffic through on the VPN.

12 Replies 12

acomiskey
Level 10
Level 10

It is normal for the vpn client gateway to match it's ip address.

Could you post the config from the ASA?

OK, wasn't 100% on the VPN client doing that.

Here's the full config IP's hidden to protect the guilty....

Your "access-list Gatling_VPN" is not applied anywhere.

The statements in your "Gatling_VPN_access_in" acl should not be needed and it should be removed.

These are ok...

access-list Gatling_VPN extended permit udp any host 147.109.253.XXX eq isakmp

access-list Gatling_VPN extended permit ah any host 147.109.253.XXX

access-list Gatling_VPN extended permit esp any host 147.109.253.XXX

i would add...

access-list Gatling_VPN extended permit udp any host 147.109.253.XXX eq 4500

I dont undestand the following...

access-list Gatling_VPN extended permit udp interface Gatling_VPN eq domain interface Gatling_GCC_LAN

access-list Gatling_VPN extended permit udp interface Gatling_VPN eq 3389 interface Gatling_GCC_LAN

access-list Gatling_VPN extended permit udp interface Gatling_GCC_LAN eq 3389 interface Gatling_VPN

access-list Gatling_VPN extended permit tcp interface Gatling_GCC_LAN eq 3389 interface Gatling_VPN

access-list Gatling_VPN extended permit tcp interface Gatling_VPN eq 3389 interface Gatling_GCC_LAN

access-list Gatling_VPN extended permit udp interface Gatling_GCC_LAN eq domain interface Gatling_VPN

If all you want to do is rdp to you terminal server then all you need is...

access-list Gatling_VPN permit tcp 172.16.0.0 255.255.255.0 host eq 3389

and apply the acl into vpn interface...

access-group Gatling_VPN in interface Gatling_VPN

Note: it appears that you are aware the only reason you must specify all your vpn traffic in your interface acl is you are not running "sysopt connection permit-ipsec" which would allow ipsec traffic to bypass the acl's. You could temporarily add that command and test the vpn, if it works then that will definitely point toward you acl's being the issue.

OK I have made the changes and removed all of the redundant rules...

Have added the "sysopt connection permit-ipsec" - but am still having no joy in passing traffic down the tunnel! Oh my head!

When trying an RDP session from XP, this is the error that the ASA is logging: "No translation group found for tcp src Gatling_VPN:172.16.0.1/1251 dst Gatling_GCC_LAN:10.10.0.13/3389"

You nat exemption acl is not correct. This is how it should be.

access-list Gatling_GCC_LAN_nat0_outbound permit ip 10.10.0.0 255.255.0.0 172.16.0.0 255.255.0.0

nat (Gatling_GCC_LAN) 0 access-list Gatling_GCC_LAN_nat0_outbound

Is this looking better?

Gatling-06(config)# sh access-l

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)

alert-interval 300

access-list Gatling_GCC_LAN_access_in; 5 elements

access-list Gatling_GCC_LAN_access_in line 1 remark Web Access

access-list Gatling_GCC_LAN_access_in line 2 extended permit tcp 10.10.0.0 255.255.0.0 eq www interface Gatling_GCC_WAN (hitcnt=0)

access-list Gatling_GCC_LAN_access_in line 3 remark HTTPS Traffic out

access-list Gatling_GCC_LAN_access_in line 4 extended permit tcp 10.10.0.0 255.255.0.0 eq https interface Gatling_GCC_WAN (hitcnt=0)

access-list Gatling_GCC_LAN_access_in line 5 extended permit tcp interface Gatling_GCC_LAN eq ssh interface Gatling_GCC_WAN eq ssh (hitcnt=0)

access-list Gatling_GCC_LAN_access_in line 6 extended permit icmp interface Gatling_GCC_LAN any (hitcnt=0)

access-list Gatling_GCC_LAN_access_in line 7 extended permit icmp interface Gatling_GCC_LAN interface Gatling_VPN (hitcnt=0)

access-list Gatling_GCC_WAN_access_out; 1 elements

access-list Gatling_GCC_WAN_access_out line 1 remark POP3 Traffic

access-list Gatling_GCC_WAN_access_out line 2 extended permit tcp 10.10.0.0 255.255.0.0 eq pop3 interface Gatling_GCC_WAN eq pop3 (hitcnt=0)

access-list Gatling_GCC_WAN_access_in; 1 elements

access-list Gatling_GCC_WAN_access_in line 1 remark COMSTRA FULL ACCESS

access-list Gatling_GCC_WAN_access_in line 2 extended permit tcp 203.127.116.0 255.255.255.0 interface Gatling_GCC_LAN (hitcnt=0)

access-list Gatling_GCC_LAN_nat0_outbound; 2 elements

access-list Gatling_GCC_LAN_nat0_outbound line 1 extended permit ip interface Gatling_GCC_LAN 172.16.0.0 255.255.255.192 (hitcnt=0)

access-list Gatling_GCC_LAN_nat0_outbound line 2 extended permit ip 10.10.0.0 255.255.0.0 172.16.0.0 255.255.0.0 (hitcnt=0)

access-list Gatling_VPN_authentication_Gosling-06; 1 elements

access-list Gatling_VPN_authentication_Gosling-06 line 1 remark AAA to Gosling-06

access-list Gatling_VPN_authentication_Gosling-06 line 2 extended permit tcp interface Gatling_VPN interface Gatling_GCC_LAN (hitcnt=0)

access-list Gatling_VPN_access_in; 4 elements

access-list Gatling_VPN_access_in line 1 extended permit udp interface Gatling_VPN eq radius host 10.10.0.36 eq radius (hitcnt=0)

access-list Gatling_VPN_access_in line 2 extended permit udp interface Gatling_VPN eq radius-acct host 10.10.0.36 eq radius-acct (hitcnt=0)

access-list Gatling_VPN_access_in line 3 extended permit icmp interface Gatling_VPN interface Gatling_GCC_LAN (hitcnt=0)

access-list Gatling_VPN_access_in line 4 extended permit tcp interface Gatling_VPN interface Gatling_GCC_LAN (hitcnt=0)

access-list Gatling_VPN; 5 elements

access-list Gatling_VPN line 1 extended permit udp any host 147.109.253.XXX eq isakmp (hitcnt=0)

access-list Gatling_VPN line 2 extended permit ah any host 147.109.253.XXX (hitcnt=0)

access-list Gatling_VPN line 3 extended permit esp any host 147.109.253.XXX (hitcnt=0)

access-list Gatling_VPN line 4 remark Tunnel Traffic

access-list Gatling_VPN line 5 extended permit udp any host 147.109.253.XXX eq 4500 (hitcnt=0)

access-list Gatling_VPN line 6 extended permit tcp 172.16.0.0 255.255.255.0 host 10.10.0.13 eq 3389 (hitcnt=0)

Gatling-06(config)# exit

Yes, but still don't understand where Gatling_VPN_access_in applies. It looks like you are trying to allow the firewall to send radius authentication requests to 10.10.0.36? You should not need this acl. Could we just get the new config again, it's easier that way, thanks.

OK, looks like I have some redunant rules...

Gatling-06# sh start erro

nat 0 0.0.0.0 will be identity translated for outbound

*** Output from config line 110, "nat (Gatling_GCC_LAN) 0 ..."

nat 0 172.16.0.0 will be identity translated for outbound

*** Output from config line 112, "nat (Gatling_VPN) 0 172...."

ERROR: Invalid tunnel group name

*** Output from config line 225, "tunnel-group-map default..."

Gatling-06#

A bit worrying....

Ok, try the following, I commented each so you know why they should change.

no nat (Gatling_VPN) 0 access-list Gatling_GCC_LAN_nat0_outbound

-This is not needed and is causing your error.

no nat (Gatling_GCC_LAN) 0 0.0.0.0 0.0.0.0

-This is not needed and is causing your error.

no route Gatling_VPN 10.10.0.0 255.255.255.255 147.109.139.xxx 1

-I dont understand this one, 10.10 network is your inside network, why would it be routed out your vpn interface?

no access-list Gatling_VPN_access_in extended permit icmp interface Gatling_VPN interface Gatling_GCC_LAN

no access-list Gatling_VPN_access_in extended permit tcp interface Gatling_VPN interface Gatling_GCC_LAN

no access-group Gatling_VPN_access_in in interface Gatling_VPN

-this acl is not needed and should be removed

access-group Gatling_VPN in interface Gatling_VPN

-applies the Gatling_VPN acl to the vpn interface, this acl allows the vpn connection and rdp connection to terminal server.

same-security-traffic permit intra-interface

-needed since you are attmempting to nat vpn clients on vpn interface

Also, you other access-list statements are really confusing. For instance you do not need to use a source port, for instance you have

access-list Gatling_GCC_LAN_access_in extended permit tcp 10.10.0.0 255.255.0.0 eq https interface Gatling_GCC_WAN

You are attempting to allow https traffic from GCC_LAN outbound, all you need is

access-list Gatling_GCC_LAN_access_in extended permit tcp 10.10.0.0 255.255.0.0 any eq https

You also have the keyword "interface" continually throughout your acl's which you should not need. I would suggest getting rid of the inside access list until you get up and running. Then you can add an acl to restrict traffic.

no access-group Gatling_GCC_LAN_access_in in interface Gatling_GCC_LAN

I hope you don't think I'm running you in circles here, there's just a lot to fix.

No and I appreciate the help - it has been a couple of years since I played with Cisco gear, so I am sadly out of practical experience!

Made the changes and have re-posted the config.

Getting closer as I can see in the ASA's ADSM live logs that the client is passing TCP 3389 traffic through - but it is no being passed back up. Authentication via our 2003 IAS server is working and the tunnel can be brought up.

That's good, we're making progress.

-Not needed as this traffic is already nat exempt

no nat (Gatling_VPN) 0 172.16.0.0 255.255.255.0 dns outside

Any errors on the ASA when you are trying to pass traffic? As long as the default gateway of the terminal server is the inside of the asa, this is not a routing problem. Be sure on your vpn client you have transparent tunneling enabled, ipsec over udp.

Thanks have made those changes, but as the attchement shows - after the client connects still not able to pass traffic to the Terminal Server....

But after the change to the client, it is no longer logging the request on the ASA....

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: