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)
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.
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.
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
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
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...