SSL VPN and Hairpining

roadhouse1387 · ‎02-22-2010

Hi,

I have a 5505 configured as part of an SSL VPN pilot. Terminating SSL VPNs is the only thing this box is doing and by and large its working ok except that I cant seem to get traffic between SSL VPN clients.

The clients have IP Softphone, the call set up is working fine as this traffic is between servers and client. But the RTP traffic is not flowing between the peers on the VPN. They are all getting rfc1918 addressing from a DHCP server on the internal network and so are in the same subnet.

I can see that the peer to peer traffic will need to hairpin on the outside interface and so I have configured the 'same-security-interface permit intra' command configured but I think I must be missing something else as its not working. Here is a clip of the relevent config...

same-security-traffic permit intra-interface
access-list nonat extended permit ip any 10.YY.208.0 255.255.240.0 (VPN CLIENT ADDRESSES)

nat (Inside) 0 access-list nonat
static (Inside,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0
route outside 0.0.0.0 0.0.0.0 PUBLICADDRESS 1
route Inside 10.0.0.0 255.0.0.0 172.XX.20.2 1
route outside 10.YY.208.0 255.255.240.0 PUBLICADDDRESS 1

VPN clients are addressed from the 10YY.208.0/20 subnet. I have no ACL in the inside interface while troubleshooting this issue. There is no outside ACL either and VPN traffic is configured to bypass the outside ACL and NAT processes.

I'm sure i'm missing somethingn simple here, but cant quite see it.

Any suggestions ?

Cheers

Shaun

busterswt · ‎02-22-2010

Where is the ACL used for the encryption domain? This is the ACL used by the client VPN software to inject the routes into the host PC. You likely have the server subnet defined here. If you want client <-> client communication, you'll also need to put the client vpn subnet there as well.

roadhouse1387 · ‎02-23-2010

Hi James,

Thanks for the input.

I'm kind of in and out of firewalls these days and so can be a bit rusty from time to time so please bear with me. Are you refering to ACL's identifying intersting traffic which would normally be configured in a Crypto Map ? I thought these were only needed in IPSEC configs ?

I dont have any configured for my SSL VPN tunnels (config below) and I have full access apart from the VPN Client to VPN Client traffic. Should I have one ?

group-policy SSLClientPolicy attributes
wins-server value 10.AA.132.15 10.BB.254.42
dns-server value 10.AA.132.15 10.BB.254.42
dhcp-network-scope 10.YY.208.0
vpn-filter none
vpn-tunnel-protocol svc
default-domain value cos.somedomainname.local
webvpn
svc modules value vpngina
svc profiles value SBLTND
svc ask none default svc

tunnel-group SSLClientProfile type remote-access
tunnel-group SSLClientProfile general-attributes
authentication-server-group MS-LDAP
default-group-policy SSLClientPolicy
dhcp-server 10.YY.132.25
tunnel-group SSLClientProfile webvpn-attributes
group-alias SLLClient enable

Cheers

Shaun

roadhouse1387 · ‎02-23-2010

Just have some further info...

I think this is a routing problem.

when I send traffic from one VPN client to another VPN client, for a test I used FTP between 10.YY.208.10 and 10.YY.208.11 I can see the TCP SYN going out on the inside interface !

Even though my routing table looks like this....

Gateway of last resort is APUBLICIP to network 0.0.0.0

C    APUBLICIP 255.255.255.224 is directly connected, outside
C    172.DD.EE.0 255.255.255.0 is directly connected, Inside
S    10.0.0.0 255.0.0.0 [1/0] via 172.DD.EE.2, Inside
S    10.YY.208.10 255.255.255.255 [1/0] via APUBLICIP , outside

S    10.YY.208.11 255.255.255.255 [1/0] via APUBLICIP , outside
S    10.YY.208.0 255.255.240.0 [1/0] via APUBLICIP , outside
S    10.YY.224.0 255.255.252.0 [1/0] via 172.DD.EE.1, Inside
S*   0.0.0.0 0.0.0.0 [1/0] via APUBLICIP , outside

Grateful for any help.

Cheers

Shaun

busterswt · ‎02-23-2010

Hi Shaun,

Sorry for the confusion. I mentioned the crypto ACL since I am used to configuring split-tunnel. It is applicable to either IPSec or SSL VPN. If not specified in the config then the default is tunnelall, which should be fine in your case.

I have successfully configured hairpinning between multiple SSL VPN clients in the past, but the difference between our configs is that my ASA was the DHCP server for VPN clients and I only had a default route outside statement (0.0.0.0/0).

I'm sorry, but I'm not able to see what is wrong with your configuration, although it does sound like a routing problem like you mentioned.

roadhouse1387 · ‎02-23-2010

Hi James,

No problem and thanks for your input.

I have just solved it. Turns out it was an errant static (inside, outside) no nat translation which I hadnt seen.

Removed that and i now works as i should. I should have seen that to be honest. Bit of a 'donkey' moment there.

Thanks for the assistance James.

Cheers

Shaun