cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
423
Views
0
Helpful
2
Replies

Access for VNC from VPN clients (on ASA5520) to branch thin clients (on ASA5525)

weichenberger1
Level 1
Level 1

We have two firewalls. One is an ASA 5520 that allows internal customers to connect via VPN to the network. The other firewall is an ASA 5525 through many of our stores connect via EZVPN. Both the the VPN internal customers and the stores use private 10.x.x.x subnets but no overlap. I am trying to allow internal customers to access the thin clients at the stores through their VPN connection and the store's EZVPN connection. I did the following packet trace and the packet was dropped. Can someone tell me why? In order to allow the access that I mentioned, I am thinking to add an inside route on the RAS firewall to store subnet of their private address. This inside static route would point to the IP of our N5000 switch Vlan6. There is an route from the N5000 to the Store firewall to the store. I am able to ping the private IP address on the stores' routers from Vlan 6 of the N5000. The inside static route that I am thinking about would like like this. Does it look correct? FYI, the packet-trace was intended to this inside route.

route inside 10.26.50.0 255.255.255.0 10.26.208.1 10

 

ASA-RAS# packet-tracer input outside tcp 10.26.206.222 5900 10.26.50.100 5900 detail

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         Outside

Phase: 3
Type: ACCESS-LIST
Subtype: aaa-user
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcd6fb668, priority=12, domain=aaa-user, deny=false
        hits=15, user_data=0xa, cs_id=0x0, flags=0x0, protocol=0
        src ip=10.26.206.222, mask=255.255.255.255, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc88fa090, priority=3, domain=permit, deny=false
        hits=6278348, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc894b870, priority=0, domain=permit-ip-option, deny=true
        hits=20520035, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 6
Type: CP-PUNT
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcd61aca8, priority=89, domain=punt, deny=true
        hits=2702, user_data=0xc834c740, cs_id=0x0, flags=0x0, protocol=0
        src ip=10.26.206.222, mask=255.255.255.255, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcd083f90, priority=69, domain=ipsec-tunnel-flow, deny=false
        hits=2720, user_data=0x7a050f4, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=10.26.206.222, mask=255.255.255.255, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (Outside) 10 access-list VPN_CLIENTS
  match ip Outside 10.26.206.0 255.255.254.0 Outside any
    dynamic translation to pool 10 (199.178.201.17 [Interface PAT])
    translate_hits = 5769728, untranslate_hits = 475684
Additional Information:
Dynamic translate 10.26.206.222/5900 to 199.178.201.17/22748 using netmask 255.255.255.255
 Forward Flow based lookup yields rule:
 in  id=0xc89cc760, priority=2, domain=nat, deny=false
        hits=5880596, user_data=0xc89cc6c0, cs_id=0x0, flags=0x0, protocol=0
        src ip=10.26.206.0, mask=255.255.254.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (Outside) 10 access-list VPN_CLIENTS
  match ip Outside 10.26.206.0 255.255.254.0 Outside any
    dynamic translation to pool 10 (199.178.201.17 [Interface PAT])
    translate_hits = 5769902, untranslate_hits = 475712
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc89cca78, priority=2, domain=host, deny=false
        hits=15717001, user_data=0xc89cc6c0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=10.26.206.0, mask=255.255.254.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xc894b870, priority=0, domain=permit-ip-option, deny=true
        hits=20520036, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 11
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 out id=0xcc78a4e0, priority=70, domain=encrypt, deny=false
        hits=2999, user_data=0x7a018bc, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.26.206.222, mask=255.255.255.255, port=0, dscp=0x0

Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (ipsec-spoof) IPSEC Spoof detected

2 Replies 2

AllertGen
Level 3
Level 3

Hi, .

I tryed to search you error reason and foun this: https://supportforums.cisco.com/discussion/10930851/ipsec-spoof-detected

Maybe you have the same problem?

Also I don't know the full archetecture, but about this part:

input-interface: Outside

......
output-interface: Outside

......

If it's on the same ASA then this can be a reason for a droping too because by default you can't send the packets back from the same interface (if you getting a packet by "outside" interface you can't use it anymore for sending this packet). Maybe the problem can be here too.

The VPN users on the Remote access firewall come in on the outside interface of the Remote Access firewall and then, in order to connect to the store routers would go out the inside interface of the remote access firewall. So, these are two different firewalls and there is not need for traffic to go back out the same interface on one firewall.