01-20-2014 07:45 AM - edited 02-21-2020 07:27 PM
Hi all,
Recently, I'm helping my client to setup a remote access vpn to the Cisco ASA 5510 to access public internet the objective is to bypass their own local firewall. Remote access vpn is working fine, VPN client connected and able access Internet. But the client request to access the Cisco ASA 5510 outside segment web hosting but this could not work.
Cisco ASA Outside IP : x.x.x.1
Cisco ASA Outside reverse static : x.x.x.100
Once VPN client connected will get the IP address : 192.168.20.10
Once VPN client connected able to access Internet after below configuration done
--cmd---
nat (outside) 1 192.168.20.0 255.255.255.0
global (outside) 1 interface
------------
Problem:
After VPN connected, VPN client not able to connect outside reverse static IP: x.x.x.100 port 80.
Hope someone can enlighten me on this matter.
attached diagram
thanks
01-20-2014 08:22 AM
Hi,
I am not sure what the NAT setup is about with the 2 different devices.
What type of VPN Client connection is this? Is it Full Tunnel or Split Tunnel?
If its Full Tunnel then the connection from the Client to any destination IP address should reach the ASA and from there on in its probably an NAT/ACL/VPN Filter ACL issue.
If its Split Tunnel then would naturally need to make sure that the server IP to which you want to connect should be in the Split Tunnel ACL so the traffic would be tunneled to the ASA.
Though now that I look at it, it seems you are using Full Tunnel as you mention adding the Dynamic PAT configuration enables Internet browsing.
Have you monitored the ASA logs while attempting this connection through the VPN?
- Jouni
01-20-2014 06:29 PM
Hi Jouni,
Is Full Tunnel VPN access. The traffic is like after user connected VPN then able to access Internet but after that then need to u-turn back to access the ASA outside hosting IP address.
The logging is showing SYN SENT.
rgds,
Frankie
01-20-2014 11:21 PM
Hi,
If the VPN Client is Full Tunnel then the ASA should be the first device that sees the actual traffic destined to your public IP addresses configured on the ASA.
Have you confirmed that these servers dont have NAT0 configurations towards the VPN Pool which might mess with the connectivity? I mean if they have their normal Static NAT configuration on the ASA to external inbound/outbound access and also NAT0 for VPN connections?
If that is the case then you might have to modify the NAT0 rules for these servers.
I guess you could try to test this with "packet-tracer". For example log in with VPN and check the IP address the host gets then try
packet-tracer input outside tcp
And share that output here while removing any actual public IP address from the output.
- Jouni
01-20-2014 11:31 PM
Hi Jouni,
There is no NAT0 configuration towards VPN pool.
below is the snapshot for packet-tracer.
ING-EDGE-ASA# packet-tracer input outside tcp 192.168.20.10 2999 xx.xx.xx.100 $
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) xx.xx.xx.100 192.168.1.100 netmask 255.255.255.255
nat-control
match ip inside host 192.168.1.100 outside any
static translation to xx.xx.xx.100
translate_hits = 179, untranslate_hits = 6511
Additional Information:
NAT divert to egress interface inside
Untranslate xx.xx.xx.100/0 to 192.168.1.100/0 using netmask 255.255.255.255
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside in interface outside
access-list outside extended permit ip any any
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (outside) 1 192.168.20.0 255.255.255.0
nat-control
match ip outside 192.168.20.0 255.255.255.0 outside any
dynamic translation to pool 1 (xx.xx.xx.101 [Interface PAT])
translate_hits = 7886, untranslate_hits = 2501
Additional Information:
Phase: 8
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) xx.xx.xx.100 192.168.1.100 netmask 255.255.255.255
nat-control
match ip inside host 192.168.1.100 outside any
static translation to xx.xx.xx.100
translate_hits = 179, untranslate_hits = 6511
Additional Information:
Phase: 10
Type: HQF
Subtype: hierarchical-queueing
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) xx.xx.xx.100 192.168.1.100 netmask 255.255.255.255
nat-control
match ip inside host 192.168.1.100 outside any
static translation to xx.xx.xx.100
translate_hits = 179, untranslate_hits = 6511
Additional Information:
Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 13
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 14
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 10861671, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
01-20-2014 11:41 PM
Hi,
The output doesnt seem to indicate any problem in the configuration. It matches the Static NAT for the destination IP address is forwarded to the "inside" interface.
Could there be any problem related to routing the traffic back to the VPN ASA from the other device in the LAN network? Or could there be something blocking the traffic there?
If you want definitive answer to the question if traffic is going through the VPN ASA and going to the internal LAN and if anything is coming back you can configure capture on the ASA in the following way
access-list VPN-CAP permit ip
access-list VPN-CAP permit ip host
capture VPN-CAP type raw-data access-list VPN-CAP interface inside buffer 5000000 circular-buffer
Then you can log in with the VPN Client while having management connection to the ASA. Then test connection to the server with some TCP based connection. Naturally you can also try ICMP if that is allowed.
Then check the output of
show capture
This will show if there is anything hit in the capture
Then you can use this command to view the actual contents on the CLI (only really good for really small amount of data captured)
show capture VPN-CAP
To copy the capture to some local host and open the capture with Wireshark for easier analysis you can use the command
copy /pcap capture:VPN-CAP tftp://x.x.x.x/VPN-CAP.pcap
You can remove the capture and its data from the ASA with
no capture VPN-CAP
This should clearly show us if the traffic is going from the VPN Client to the internal LAN and server and if anything is coming back. If not, then have to look for the problem on the other devices.
Notice that the IP address used as the server IP in the capture ACL is the IP address after the UN-NAT. The local IP address for this VPN ASA in other words.
Hope this helps
- Jouni
02-09-2014 09:33 PM
Hi Jouni,
Problem solved after internal firewall rules tuning. Many thanks your response.
rgds,
Frankie
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide