Allow access for a VPN Client to a spoke network through ASA5520 running 8.4(3)

Unanswered Question
Mar 27th, 2012
User Badges:

I'm trying to set-up 3 remote access groups on an ASA5520 running version 8.4(3) software so that remote clients connected via Cisco VPN Client can also access spoke networks which are also connected to the ASA.   I've previously set this up on ASAs running v7.2 software without issue but don't seem to be able to do the same here and can't for the life of me figure out what's wrong!


I have set-up the 3 remote access groups:


Group 1 - subnet 192.168.1.48/28
Group 2 - subnet 192.168.2.0/25
Group 3 - subnet 192.168.3.0/25


My remote access user groups can all connect to the head office subnet (10.0.0.0/8) without issue.  But only one of the groups (192.168.1.48/28) appears to be able to access the spoke sites (172.30.10.0/24 and 172.30.20.0/24) that I have set-up.  However, I can't see what the difference is between the 3 groups I have configured so can't understand why it works ok for one group and not the others?


When I use the packet tracer, it tells me that the flow is being dropped at the VPN encryption phase but why is that?  How can I find out more?

Here's the relevant config on my ASA:


!
same-security-traffic permit intra-interface
!
crypto dynamic-map remoteuser 5 set transform-set ESP-3DES-MD5
crypto dynamic-map remoteuser 5 set security-association lifetime seconds 28800
crypto dynamic-map remoteuser 5 set security-association lifetime kilobytes 4608000
!
crypto map outside_map 65000 ipsec-isakmp dynamic remoteuser
!
ip local pool pool1clients 192.168.1.49-192.168.50.54
ip local pool pool2clients 192.168.2.1-192.168.2.126
ip local pool pool3clients 192.168.3.1-192.168.3.126
!
access-list split-tunnel-pool1 standard permit 10.0.0.0 255.0.0.0
access-list split-tunnel-pool1 standard permit 172.30.10.0 255.255.255.0
access-list split-tunnel-pool1 standard permit 172.30.20.0 255.255.255.0 
!
access-list split-tunnel-pool2 standard permit 10.0.0.0 255.0.0.0
access-list split-tunnel-pool2 standard permit 172.30.10.0 255.255.255.0
access-list split-tunnel-pool2 standard permit 172.30.20.0 255.255.255.0 
!
access-list split-tunnel-pool3 standard permit 10.0.0.0 255.0.0.0
access-list split-tunnel-pool3 standard permit 172.30.10.0 255.255.255.0
access-list split-tunnel-pool3 standard permit 172.30.20.0 255.255.255.0 
!
!
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ (inside) host 10.10.10.132
key *****
aaa-server RADIUS protocol radius
aaa-server RADIUS (inside) host 10.10.10.132
key *****
!
group-policy POOL1VPN internal
group-policy POOL1VPN attributes
wins-server value 10.10.10.29
dns-server value 10.10.10.35 10.10.10.48
vpn-idle-timeout 30
ipsec-udp enable
ipsec-udp-port 10000
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-tunnel-pool1
default-domain value test.pri
!
tunnel-group POOL1VPN type ipsec-ra
tunnel-group POOL1VPN general-attributes
address-pool pool1clients
authentication-server-group RADIUS
accounting-server-group RADIUS
default-group-policy POOL1VPN
tunnel-group POOL1VPN ipsec-attributes
pre-shared-key *****
!
!
group-policy POOL2VPN internal
group-policy POOL2VPN attributes
wins-server value 10.10.10.29
dns-server value 10.10.10.35 10.10.10.48
vpn-idle-timeout 30
ipsec-udp enable
ipsec-udp-port 10000
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-tunnel-pool2
default-domain value test.pri
!
tunnel-group POOL2VPN type ipsec-ra
tunnel-group POOL2VPN general-attributes
address-pool pool2clients
authentication-server-group RADIUS
accounting-server-group RADIUS
default-group-policy POOL2VPN
tunnel-group POOL2VPN ipsec-attributes
pre-shared-key *****
!
!
group-policy POOL3VPN internal
group-policy POOL3VPN attributes
wins-server value 10.10.10.29
dns-server value 10.10.10.35 10.10.10.48
vpn-idle-timeout 30
ipsec-udp enable
ipsec-udp-port 10000
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split-tunnel-pool3
default-domain value test.pri
!
tunnel-group POOL3VPN type ipsec-ra
tunnel-group POOL3VPN general-attributes
address-pool pool3clients
authentication-server-group RADIUS
accounting-server-group RADIUS
default-group-policy POOL3VPN
tunnel-group POOL3VPN ipsec-attributes
pre-shared-key *****
!
object network obj-10.0.0.0
subnet 10.0.0.0 255.0.0.0
!
object network obj-192.168.1.48-mask28
subnet 192.168.1.48 255.255.255.240
!
object network obj-192.168.2.0-mask25
subnet 192.168.2.0 255.255.255.128
!
object network obj-192.168.3.0-mask25
subnet 192.168.3.0 255.255.255.128
!
object network obj-172.30.10.0-mask24
subnet 172.30.10.0 255.255.255.0
!
object network obj-172.30.20.0-mask24
subnet 172.30.20.0 255.255.255.0
!
nat (inside,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-192.168.1.48-mask28 obj-192.168.1.48-mask28
nat (inside,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-192.168.2.0-mask25 obj-192.168.2.0-mask25
nat (inside,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-192.168.3.0-mask25 obj-192.168.3.0-mask25
nat (inside,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-172.30.10.0-mask24 obj-172.30.10.0-mask24
nat (inside,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
!
nat (inside,OUTSIDE) source static static obj-192.168.1.48-mask28 obj-192.168.1.48-mask28 destination static obj-172.30.10.0-mask24 obj-172.30.10.0-mask24
nat (inside,OUTSIDE) source static static obj-192.168.1.48-mask28 obj-192.168.1.48-mask28 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
!
nat (inside,OUTSIDE) source static static obj-192.168.2.0-mask25 obj-192.168.2.0-mask25 destination static obj-172.30.10.0-mask24 obj-172.30.10.0-mask24
nat (inside,OUTSIDE) source static static obj-192.168.2.0-mask25 obj-192.168.2.0-mask25 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
!
nat (inside,OUTSIDE) source static static obj-192.168.3.0-mask25 obj-192.168.3.0-mask25 destination static obj-172.30.10.0-mask24 obj-172.30.10.0-mask24
nat (inside,OUTSIDE) source static static obj-192.168.3.0-mask25 obj-192.168.3.0-mask25 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
!
access-list spoke1 extended permit ip 10.0.0.0 255.0.0.0 172.30.10.0 255.255.255.0
access-list spoke1 extended permit ip 192.168.1.48 255.255.255.240 172.30.10.0 255.255.255.0
access-list spoke1 extended permit ip 192.168.2.0 255.255.255.128 172.30.10.0 255.255.255.0
access-list spoke1 extended permit ip 192.168.3.0 255.255.255.128 172.30.10.0 255.255.255.0
!
access-list spoke2 extended permit ip 10.0.0.0 255.0.0.0 172.30.20.0 255.255.255.0
access-list spoke2 extended permit ip 192.168.1.48 255.255.255.240 172.30.20.0 255.255.255.0
access-list spoke2 extended permit ip 192.168.2.0 255.255.255.128 172.30.20.0 255.255.255.0
access-list spoke2 extended permit ip 192.168.3.0 255.255.255.128 172.30.20.0 255.255.255.0
!


On the remote routers (Cisco 2911s running version 15.1(4)M) I have the relevant access-lists set-up allowing "interesting" traffic from the site subnets to the remote access subnets and also the relevant "no NAT" ACL for these subnets. e.g.


!

ip access-list extended headoffice
10 permit ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255
20 permit ip 172.30.10.0 0.0.0.255 192.168.1.48 0.0.0.15
30 permit ip 172.30.10.0 0.0.0.255 192.168.2.0 0.0.0.128
40 permit ip 172.30.10.0 0.0.0.255 192.168.3.0 0.0.0.128
!
ip access-list extended nonat
10 deny ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255
20 deny ip 172.30.10.0 0.0.0.255 192.168.1.48 0.0.0.15
30 deny ip 172.30.10.0 0.0.0.255 192.168.2.0 0.0.0.128
40 deny ip 172.30.10.0 0.0.0.255 192.168.3.0 0.0.0.128

!


Here's a sample from packet tracer showing the one that works:


Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x748067a0, priority=70, domain=encrypt, deny=false
        hits=1, user_data=0xc3ff1c, cs_id=0x7487e0f8, reverse, flags=0x0, protocol=0
        src ip/id=192.168.1.48, mask=255.255.255.240, port=0
        dst ip/id=172.30.10.0, mask=255.255.255.0, port=0, dscp=0x0
        input_ifc=any, output_ifc=OUTSIDE

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in  id=0x74971ec0, priority=69, domain=ipsec-tunnel-flow, deny=false
        hits=1, user_data=0xc40e1c, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=172.30.10.0, mask=255.255.255.0, port=0
        dst ip/id=192.168.1.48, mask=255.255.255.240, port=0, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=any


And here's the packet trace for one that doesn't work:



Phase: 8

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

out id=0x749de330, priority=70, domain=encrypt, deny=false

        hits=600, user_data=0x0, cs_id=0x7487e0f8, reverse, flags=0x0, protocol=0

        src ip/id=192.168.2.0, mask=255.255.255.128, port=0

        dst ip/id=172.30.10.0, mask=255.255.255.0, port=0, dscp=0x0

        input_ifc=any, output_ifc=OUTSIDEPhase: 8
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x749de330, priority=70, domain=encrypt, deny=false
        hits=600, user_data=0x0, cs_id=0x7487e0f8, reverse, flags=0x0, protocol=0
        src ip/id=192.168.2.0, mask=255.255.255.128, port=0
        dst ip/id=172.30.10.0, mask=255.255.255.0, port=0, dscp=0x0
        input_ifc=any, output_ifc=OUTSIDE


Can anyone suggest why this only works for one of my remote access groups?  What else can I do to find out why I can't connect to the spokes for the other remote access groups?  Or do you have any suggestions on what I can do to resolve this?


Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Jouni Forss Tue, 03/27/2012 - 07:40
User Badges:
  • Super Bronze, 10000 points or more

Hi,


So are you saying that you are configuring 3 Remote Access VPN groups for VPN Client access and you also have two remote sites connected with L2L VPN to the central ASA? And connections between the Client users and the L2L VPN remote sites isn't working?


What first came to my mind is that shouldn't you have the NAT statements for Client to Remote site traffic using "outside" interface as both the source and destination interface? Or where are the 172.30.x.x/24 networks located?


Looking at your configurations above, I mean the following lines


nat (OUTSIDE,OUTSIDE)  source static static obj-192.168.1.48-mask28 obj-192.168.1.48-mask28  destination static obj-172.30.10.0-mask24 obj-172.30.10.0-mask24

nat  (OUTSIDE,OUTSIDE) source static static obj-192.168.1.48-mask28  obj-192.168.1.48-mask28 destination static obj-172.30.20.0-mask24  obj-172.30.20.0-mask24

!

nat  (OUTSIDE,OUTSIDE) source static static obj-192.168.2.0-mask25  obj-192.168.2.0-mask25 destination static obj-172.30.10.0-mask24  obj-172.30.10.0-mask24

nat  (OUTSIDE,OUTSIDE) source static static obj-192.168.2.0-mask25  obj-192.168.2.0-mask25 destination static obj-172.30.20.0-mask24  obj-172.30.20.0-mask24

!

nat  (OUTSIDE,OUTSIDE) source static static obj-192.168.3.0-mask25  obj-192.168.3.0-mask25 destination static obj-172.30.10.0-mask24  obj-172.30.10.0-mask24

nat  (OUTSIDE,OUTSIDE) source static static obj-192.168.3.0-mask25  obj-192.168.3.0-mask25 destination static obj-172.30.20.0-mask24  obj-172.30.20.0-mask24


- Jouni

mitchen Tue, 03/27/2012 - 08:18
User Badges:

Hi Jouni,


thanks for the response.


The closest I can find to what I am trying to achieve is shown in this guide - but this is for ASA7.2 whereas I am using ASA8.4(3):


http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008046f307.shtml


But what I am saying is that, yes, I am configuring 3 remote access VPN groups for VPN Client access and that I also have two remote sites connected to the central ASA.  However, one of my remote access groups successfully allows connections between the client users and the L2L remote VPN sites - whereas the other 2 groups don't, they are only allowing the client users to connect to the head office.   I can't figure out why this should be?  I want all 3 remote access groups to be able to also connect to these remote sites.


I can't see anything different in the config between my 3 groups so don't know why it works for 1 group (the first that I set-up) but not the others?


I'm prepared to be proven wrong on this but i think my NAT statements are correct (at least, if they are not, then why does it work ok for one of the remote access groups?)   In any case, I have just tried changing them as you suggested but it made no difference.


Any more suggestions are welcome though!

Jouni Forss Tue, 03/27/2012 - 09:21
User Badges:
  • Super Bronze, 10000 points or more

Hi,


Have you tried all the remote access VPN to L2L VPN connections (for example ICMP) from an actual remote computer or just packet tracer?


Is it possible that there would be any overriding NAT configuration on the ASA? For example some type of translation for the VPN Pool addresses to the Internet before the above mentioned rules? If the VPN rules were configured on the CLI they would just go in that order while on ASDM you could insert them where you wanted (think though that the CLI also has the "line number" on where to insert the NAT line)


I mean something like


nat (OUTSIDE,OUTSIDE) source dynamic obj-192.168.2.0-mask25 interface


Though this is just guessing from my point. Does seem strange it doesnt work at the moment.


I once had a situation where such a  NAT overrided one of my static NATs. I added "after-auto" after the ")" to take the PAT rule at the very bottom when using "show run nat".




Could you perhaps copy/paste or attach on a file the full packet-tracer command and its output that you were doing in the CLI when testing the working and not working connection.


Somehow I was under the impression that "packet-tracer" can't be used to simulate VPN traffic arriving from outside interface. Think it usually gave an error message of "ipsec spoof" or something like that.


- Jouni

mitchen Tue, 03/27/2012 - 09:48
User Badges:

Hi Jouni,


thanks again for the further input.


I've tried the remote access VPN to L2L VPN connections from actual remote computers aswell as the packet tracer and get the same results (i.e. from a "pool1" client I can connect to the remote sites without issue, from "pool2" and "pool3" clients I can only connect to head office)


I don't think there is any overriding NAT configuration on the ASA but I've been looking at this till my head hurts so I may well have missed something! As far as I can see, there is no difference in the config between the 3 different remote access groups.


Here's the full packet tracer output for the working connection:


packet-tracer input inside icmp 192.168.1.50 0 8 172.30.20.254

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         OUTSIDE

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outbound-acl in interface inside
access-list outbound-acl extended permit ip any any
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
  inspect icmp
service-policy global_policy global
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,OUTSIDE) source static obj-192.168.1.48-mask28 obj-192.168.1.48-mask28 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
Additional Information:
Static translate 192.168.1.50/0 to 192.168.1.50/0

Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 8150530, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow


And here's the full packet tracer output for the non-working connection:



packet-tracer input inside icmp 192.168.2.2 0 8 172.30.20.254

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         OUTSIDE

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outbound-acl in interface inside
access-list outbound-acl extended permit ip any any
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
  inspect icmp
service-policy global_policy global
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,OUTSIDE) source static obj-192.168.2.0-mask25 obj-192.168.2.0-mask25 destination static obj-172.30.20.0-mask24 obj-172.30.20.0-mask24
Additional Information:
Static translate 192.168.2.2/0 to 192.168.2.2/0

Phase: 9
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule


I just can't figure out what is causing it to fail?

Jouni Forss Tue, 03/27/2012 - 10:01
User Badges:
  • Super Bronze, 10000 points or more

Hi,


If you check "show crypto ipsec sa peer x.x.x.x" for the remote site L2L VPNs peer addresses, is there any mention of the SA for pool2 and pool3 address ranges?


Would it be possible that the L2L VPN just fails somehow regarding those networks between the routers and ASA? I guess the way to find out would be to debug the L2L VPN connections just to be sure whats happening. (Though those configurations seemed correct also)


It seems you are using the interface "inside" in the packet-tracer lines. I guess thats why it doesn't complain of the "spoof" or something has just changed with the software. Wouldn't the actual traffic be coming from the "outside" interface or have I myself missunderstood the command parameters somehow?

mitchen Tue, 03/27/2012 - 10:17
User Badges:

Hi,


strangely, there is no mention of the pool2 and pool3 address ranges in the "show crypto ipsec sa peer x.x.x.x" output?


I guess its possible that it fails regarding those networks between the routers and ASA but I can't see why?  I've checked and double-checked the remote routers configs and can't see anything amiss there.


It may well be me that has misunderstood the command parameters - I've never really used the packet tracer before until troubleshooting this issue!  (However, if i change the "inside" to "outside" i don't get any spoofing error message but it does say that the flow will be dropped for both pool1 and pool2 but thats not the case in reality?)


Thanks once more for your input - and if you have any further suggestions please keep them coming as I'd really like to get to the bottom of this!

Jouni Forss Tue, 03/27/2012 - 10:49
User Badges:
  • Super Bronze, 10000 points or more

Hi,


What if you generate traffic from one of the routers (or a host behind them) towards the pool2 and pool3 IP addresses (even thought they wouldnt be reachable at that moment) and then check the "show crypto ipsec sa" outputs other the router/ASA.


If after that there is still no mention of the of the networks in the show command output it would seem it somehow related to the VPN.


And at that point I would be pretty much out of ideas myself also.


I'd probably try some VPN debugging even though sometimes they confuse you more than they give information.


Theres only been one time when all my VPN configurations matched and the VPN was still the cause for the problem. Thought in that particular case the VPN endpoints were from different manufacturer. That time the debugs revealed a problem relating to the networks masks used. Even though they were matched on both sides the connection still wouldnt form. After we changed some of the network masks to abit bigger ones the connection started working.

mitchen Wed, 03/28/2012 - 02:48
User Badges:

Well,  I'm not sure if this helps at all but I started a ping from a remote VPN client (192.168.2.1) to one of my remote spoke sites (172.30.10.254) and it was timing out.   However, I enabled debugging of crypto ipsec on the remote router at the spoke site and it showed the following:


Mar 28 09:33:48.524: IPSEC(validate_proposal_request): proposal part #1

Mar 28 09:33:48.524: IPSEC(validate_proposal_request): proposal part #1,

  (key eng. msg.) INBOUND local= *.*.*.*:0, remote= *.*.*.*:0,

    local_proxy= 172.30.10.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 192.168.2.0/255.255.255.128/0/0 (type=4),

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

Mar 28 09:33:48.524: Crypto mapdb : proxy_match

        src addr     : 172.30.10.0

        dst addr     : 192.168.2.0

        protocol     : 0

        src port     : 0

        dst port     : 0

Mar 28 09:33:48.524: Crypto mapdb : proxy_match

        src addr     : 172.30.10.0

        dst addr     : 192.168.2.0

        protocol     : 0

        src port     : 0

        dst port     : 0

Mar 28 09:33:48.524: Crypto mapdb : proxy_match

        src addr     : 172.30.10.0

        dst addr     : 192.168.2.0

        protocol     : 0

        src port     : 0

        dst port     : 0

Mar 28 09:33:48.524: map_db_find_best did not find matching map

Mar 28 09:33:48.524: IPSEC(ipsec_process_proposal): proxy identities not supported


But I'm still none the wiser as to what this actually means?  Can anyone shed any light on this?

Jouni Forss Wed, 03/28/2012 - 03:10
User Badges:
  • Super Bronze, 10000 points or more

Hi,


It somehow just seems to point to the fact that the networks (althought correctly mirroring eachother) just dont match? Or some other parameters don't match. Though as the actual L2L VPNs work one would think the only other cause could be the network statements for the VPN.


Again reminds me of the problem I had that I mentioned in an earlier post.


Would it be possible to try out so that you change the encryption domain configurations so that you would just use the 192.168.0.0/16 network for the VPN configurations (ASA to Router config)


I mean change the following (and related NAT configurations)


ip access-list extended headoffice
10 permit ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255
20 permit ip 172.30.10.0 0.0.0.255 192.168.1.48 0.0.0.15
30 permit ip 172.30.10.0 0.0.0.255 192.168.2.0 0.0.0.128
40 permit ip 172.30.10.0 0.0.0.255 192.168.3.0 0.0.0.128
!
ip access-list extended nonat
10 deny ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255
20 deny ip 172.30.10.0 0.0.0.255 192.168.1.48 0.0.0.15
30 deny ip 172.30.10.0 0.0.0.255 192.168.2.0 0.0.0.128
40 deny ip 172.30.10.0 0.0.0.255 192.168.3.0 0.0.0.128


access-list spoke1 extended permit ip 10.0.0.0 255.0.0.0 172.30.10.0 255.255.255.0

access-list spoke1 extended permit ip 192.168.1.48 255.255.255.240 172.30.10.0 255.255.255.0

access-list spoke1 extended permit ip 192.168.2.0 255.255.255.128 172.30.10.0 255.255.255.0

access-list spoke1 extended permit ip 192.168.3.0 255.255.255.128 172.30.10.0 255.255.255.0



To the following


access-list spoke1 extended permit ip 10.0.0.0 255.0.0.0 172.30.10.0 255.255.255.0

access-list spoke1 extended permit ip 192.168.0.0 255.255.0.0 172.30.10.0 255.255.255.0



ip access-list extended headoffice

10 permit ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255

20 permit ip 172.30.10.0 0.0.0.255 192.168.0.0 0.0.255.255


!

ip access-list extended nonat

10 deny ip 172.30.10.0 0.0.0.255 10.0.0.0 0.255.255.255

20 deny ip 172.30.10.0 0.0.0.255 192.168.0.0 0.0.255.255



- Jouni

Jouni Forss Wed, 03/28/2012 - 04:09
User Badges:
  • Super Bronze, 10000 points or more

Oh,


And it still seems to me that the NAT should be "nat (OUTSIDE,OUTSIDE)" since the source and destination interface for the actual traffic is still the same. The connections shoudn't have anything to do with the inside interface.


But can't really say for sure as I havent configured these types of NAT/VPN yet with the new software. But I migrated a big customer NAT configurations from 8.2 -> 8.4 manually and after that to my understanding the NAT should be like that. I guess you can always test it again.


Maybe you could even configure a Loopback interface on the router and generate traffic from there (instead of the VPN Client) and see if theres any difference in the debugs and show command outputs

mitchen Thu, 03/29/2012 - 06:38
User Badges:

Well, just to update you I managed to resolve this problem though I'm still not quite sure what the actual cause was.


I basically just decided to "start again" so I deleted all the config I had and started afresh, creating new remote access user groups etc. Lo and behold, it all worked fine!  I also took the opportunity to tidy up the configs on the remote routers so I don't know if there was maybe something conflicting on there?  There was nothing obvious that I could see but there was certainly some redundant config on there so perhaps just making things more neat and tidy helped?


Anyway, all seems good now.  Incidentally, my nat statements (with it all working) are nat (inside, outside) as I had originally - I think this is correct because the traffic would traverse the inside then outside before it goes to the remote sites?  In any case, it works though I must admit I find the NAT changes post 8.3 a little confusing, think I preferred the old way!


Thanks for your help all the same, very much appreciated.

Jouni Forss Thu, 03/29/2012 - 06:45
User Badges:
  • Super Bronze, 10000 points or more

Hi,


Glad you got the problem sorted


I do agree that the new NAT format seems abit troublesome now when its still a bit new. I had personally just gotten used to the old format and BAM! Whole NAT redone.


I was under the impression that traffic from your remote sites and clients come from the outside interface? Thats why I was thinking the interfaces would be the same.


Guess its time to lab the setup some myself. We only have similiar setups with the 8.2 software. (VPN originated traffic forwarded to another VPN on the same device)

adidibra1 Tue, 03/18/2014 - 09:05
User Badges:

Hello,

Did you manage to solve your issue?

Thanks 

Actions

This Discussion

Related Content