04-23-2023 03:03 PM - edited 04-24-2023 08:32 PM
Please help!
This is a bit of a long one but I'm trying to provide as
much info as I can ....
We have a new ISR4331 and I'm trying to set it up so that
Windows 10 systems can VPN in using L2TP/IPSec tunnels.
I'm using L2TP/IPSec because I'm trying to keep it as simple
as possible for the end user. All they need is a few steps
and a magic "Shared Key" to get it up and working.
[ It seems to me that this is MUCH easier than dealing with
certificates, etc ]
Anyway, I got the ISR4331 configured so that the tunnels come
up when the user VPNs in but they don't quite work right.
The symptom is that from the Windows Client you can
ping the loopback interface on the router and it works.
You can also ping the IP address of VLAN 1010 on the router.
You can also ping the IP address of VLAN 1050 on the router.
However, pinging 10.10.10.102 fails.
10.10.10.102 is the address of the RADIUS server that the
router uses to authenticate the users.
[ Clearly it is reachable from the router as it was used
during the authentication process. Also - see below ]
If you ssh into the router you can ping 10.10.10.102
just fine, as well as basically anything else (see more
details below).
So it kindda looks like the router is not routing ......
I.E. it is not passing traffic from the 172.20 network
over to the 10.10 network/Vlan unless the target
is a known local address.
Based on the above observation I did various ping
commands whilst ssh'd into the router as follows:
Here we ping the RADIUS server which is accessed through
VLAN 1010 using the the VLAN 1010 interface.
It works fine.
RT-R1#ping 10.10.10.102 ingress vlan1010
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.102, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Now we do the same thing using VLAN 1050.
It fails ....
RT-R1#ping 10.10.10.102 ingress vlan1050
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.102, timeout is 2 seconds:
Packet sent with a source address of 10.50.1.1
.....
Success rate is 0 percent (0/5)
Then we do the same thing using the loopback interface.
It fails ...
RT-R1#ping 10.10.10.102 ingress loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.102, timeout is 2 seconds:
Packet sent with a source address of 172.20.1.1
.....
Success rate is 0 percent (0/5)
Now we just ping a random internet address to show that it works...
RT-R1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms
The we ping the same external address from the VLAN 1010 address.
It works.
RT-R1#ping 8.8.8.8 ingress vlan1010
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/7/8 ms
And then we try the same external address using the VLAN 1050 interface.
It fails.
RT-R1#ping 8.8.8.8 ingress vlan1050
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.50.1.1
.....
Success rate is 0 percent (0/5)
And the same thing using the loopback interface.
It fails.
RT-R1#ping 8.8.8.8 ingress loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.20.1.1
.....
Success rate is 0 percent (0/5)
So it sortta looks like the loopback interface and
the 1050 Vlan interface are "isolated" and traffic
is not being routed from/to them.
I may be totally confused here and if that is true
maybe someone can clarify this behavior.
I have included below various diagnostic outputs for
your enjoyment.
Any help to explain/fix this lack of routing behavior
would be greatly appreciated. The ultimate goal is
to get the VPN tunnels to work correctly but it appears
to me that the issue is some part of the configuration
of the ISR4331 as the routing issues can be demonstrated
without any involvment of VPN.
Thanks in advance !!!
>>>> Output from show ip route
Gateway of last resort is 24.145.95.161 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 24.145.95.161
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 10.10.0.0/16 is directly connected, Vlan1010
L 10.10.1.1/32 is directly connected, Vlan1010
C 10.50.0.0/19 is directly connected, Vlan1050
L 10.50.1.1/32 is directly connected, Vlan1050
24.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 24.145.95.160/29 is directly connected, GigabitEthernet0/0/0
L 24.145.95.164/32 is directly connected, GigabitEthernet0/0/0
172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.20.1.0/24 is directly connected, Loopback1
L 172.20.1.1/32 is directly connected, Loopback1
>>>>>> Output to show interfaces
RT-R1#show ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0/0 24.145.95.164 YES NVRAM up up
GigabitEthernet0/0/1 63.125.125.90 YES NVRAM administratively down down
GigabitEthernet0/0/2 unassigned YES NVRAM administratively down down
GigabitEthernet0/1/0 unassigned YES unset up up
GigabitEthernet0/1/1 unassigned YES unset down down
GigabitEthernet0/1/2 unassigned YES unset down down
GigabitEthernet0/1/3 unassigned YES unset down down
GigabitEthernet0 unassigned YES NVRAM down down
Loopback1 172.20.1.1 YES NVRAM up up
Virtual-Access1 unassigned YES unset down down
Virtual-Template1 172.20.1.1 YES unset down down
Vlan1 unassigned YES unset up up
Vlan1010 10.10.1.1 YES NVRAM up up
Vlan1050 10.50.1.1 YES NVRAM up up
>>>>>>>> Output to show which Vlans go where ...
RT-R1#show vlan br
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/1/1, Gi0/1/2, Gi0/1/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
1010 VLAN1010 active
1050 VLAN1050 active
>>>>>>> Full configuration <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!
! Last configuration change at 16:18:47 EST Sun Apr 23 2023 by admin
! NVRAM config last updated at 16:28:52 EST Sun Apr 23 2023 by admin
!
version 17.6
service timestamps debug datetime msec
service timestamps log datetime msec
service call-home
platform qfp utilization monitor load 80
platform punt-keepalive disable-kernel-core
!
hostname RT-R1
!
boot-start-marker
boot system flash bootflash:isr4300-universalk9.17.06.03a.SPA.bin
boot-end-marker
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable secret 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
aaa new-model
!
aaa group server radius RADIUS_SERVERS
server name system_a
server name system_b
!
aaa authentication enable default enable
aaa authentication ppp L2TP_A group RADIUS_SERVERS
aaa authorization exec default local
aaa authorization network default group RADIUS_SERVERS
!
aaa session-id common
clock timezone EST -5 0
clock summer-time EST recurring
!
ip dhcp excluded-address 172.20.1.0 172.20.1.29
!
ip dhcp pool DHCPSCOPE_VPN
network 172.20.1.0 255.255.255.0
domain-name cb.test.org
default-router 172.20.1.1
dns-server 10.10.10.102
lease 0 2
!
no login on-success log
!
subscriber templating
!
multilink bundle-name authenticated
vpdn enable
vpdn session-limit 100
!
vpdn-group VPN_USERS
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
!
domain foo.bar.com
!
crypto pki trustpoint SLA-TrustPoint
enrollment terminal
revocation-check crl
!
crypto pki trustpoint TP-self-signed-3332763216
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-3332763216
revocation-check none
rsakeypair TP-self-signed-3332763216
!
crypto pki certificate chain SLA-TrustPoint
certificate ca 01
30820321 30820209 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030
..... Lines removed ......
418616A9 4093E049 4D10AB75 27E86F73 932E35B5 8862FDAE 0275156F 719BB2F0
D697DF7F 28
quit
crypto pki certificate chain TP-self-signed-3332763216
certificate self-signed 01
30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
..... Lines removed ......
AB70DC35 E3A11518 BEE509DF 43020086 7B784902 6F06DF9D 08DC8A4D 38545828
B7F20360 58E1E207 B7653409 0E39FA47 0A40F1CD
quit
!
crypto pki certificate pool
! ('certificate ca' cmd has been deprecated. Downloaded
! Trustpool certificates should be re-downloaded
! using 'crypro pki trustpool import url <url>')
!
no license feature hseck9
license udi pid ISR4331/K9 sn SERNUM123
license boot level appxk9
license boot level securityk9
license smart transport callhome
memory free low-watermark processor 67107
!
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
username admin privilege 15 secret 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
username test privilege 0 secret 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
!
redundancy
mode none
!
vlan internal allocation policy ascending
!
vlan 1010,1050
!
lldp run
!
crypto isakmp policy 5
encryption 3des
hash sha
authentication pre-share
group 14
lifetime 3600
!
crypto isakmp policy 10
encryption 3des
hash sha
authentication pre-share
group 2
lifetime 3600
crypto isakmp key XXXXXXXX address 0.0.0.0
!
crypto ipsec transform-set VPN_TR_SET esp-3des esp-sha-hmac
mode transport
!
crypto dynamic-map VPN_DYN_MAP 10
set nat demux
set transform-set VPN_TR_SET
!
crypto map VPN_CRY_MAP 100 ipsec-isakmp dynamic VPN_DYN_MAP
!
interface Loopback1
ip address 172.20.1.1 255.255.255.0
ip nat inside
!
interface GigabitEthernet0/0/0
description Copper port on outside top
ip address 24.145.95.164 255.255.255.248
ip nat outside
negotiation auto
crypto map VPN_CRY_MAP
!
interface GigabitEthernet0/0/1
description CB2C1 - Copper port on outside bottom
ip address 63.125.125.90 255.255.255.252
ip nat outside
shutdown
negotiation auto
!
interface GigabitEthernet0/0/2
description SFP port on inside bottom
ip address dhcp
shutdown
negotiation auto
!
interface GigabitEthernet0/1/0
description NIM port top left - Copper
switchport access vlan 1010
switchport trunk native vlan 1010
switchport mode trunk
!
interface GigabitEthernet0/1/1
description NIM port bottom left - Copper
!
interface GigabitEthernet0/1/2
description NIM port top right - Copper
!
interface GigabitEthernet0/1/3
description NIM port bottom right - Copper
!
interface GigabitEthernet0
description Management Interface - Front - Copper
vrf forwarding Mgmt-intf
no ip address
negotiation auto
!
interface Virtual-Template1
description Template for VPN connections
ip unnumbered Loopback1
ip nat inside
peer default ip address pool NEW_POOL
ppp authentication ms-chap ms-chap-v2 L2TP_A
ppp ipcp dns 10.10.10.102 8.8.8.8
ppp ipcp route default
!
interface Vlan1
no ip address
!
interface Vlan1010
ip address 10.10.1.1 255.255.0.0
ip nat inside
!
interface Vlan1050
ip address 10.50.1.1 255.255.224.0
ip nat inside
!
ip local pool NEW_POOL 172.20.1.41 172.20.1.141
ip http server
ip http authentication local
ip http secure-server
ip http session-idle-timeout 1200
ip http client source-interface Vlan1
ip forward-protocol nd
ip tftp source-interface GigabitEthernet0/1/0
ip nat inside source list 101 interface GigabitEthernet0/0/0 overload
ip route 0.0.0.0 0.0.0.0 24.145.95.161
ip ssh maxstartups 50
ip ssh version 2
ip ssh pubkey-chain
username admin
key-hash ssh-rsa YYYYYYYYYYYYYYYYYYY XXXXX@SYS31
ip ssh server peruser session limit 16
!
ip access-list extended 101
10 deny ip any 172.20.1.0 0.0.0.255
20 permit ip 10.10.0.0 0.0.255.255 any
!
snmp-server community public RO
snmp-server location 2nd Flr Hub Rm
!
radius server system_b
address ipv4 10.10.10.102 auth-port 1812 acct-port 1813
pac key XXXXXXXXXXXX
!
radius server system_a
address ipv4 10.10.12.100 auth-port 1812 acct-port 1813
pac key XXXXXXXXXXXX
!
control-plane
!
line con 0
exec-timeout 0 0
stopbits 1
line aux 0
line vty 0 4
exec-timeout 0 0
length 0
transport input telnet ssh
line vty 5 8
exec-timeout 0 0
length 0
transport input telnet ssh
line vty 9 14
transport input ssh
!
call-home
! If contact email address in call-home is configured as sch-smart-licensing@cisco.com
! the email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications.
contact-email-addr sch-smart-licensing@cisco.com
data-privacy level high
profile "CiscoTAC-1"
active
destination transport-method http
ntp server ip pool.time.org
ntp server ip time.windows.com
ntp server ip time-d-g.nist.gov prefer
!
end
04-26-2023 11:44 AM
There is much about your explanation that I do not understand well. But I am wondering about how you have configured nat. This is the acl that controls nat
ip access-list extended 101
10 deny ip any 172.20.1.0 0.0.0.255
20 permit ip 10.10.0.0 0.0.255.255 any
I am puzzled why you are denying nat for traffic whose destination is the vpn subnet. But what is clear is that the only traffic to be translated is in 10.10.0.0 which clearly excludes any vpn client traffic.
04-27-2023 10:13 AM
Rick,
Thanks for your reply.
I must admit that it is not clear to me exactly how that ACL is used.
(or even if it is needed). The interface that gets created for the
tunnel is a sub-interface of loopback1 which is set to "IP NAT INSIDE"
so it would seem to me that for the tunnel nothing further should be
required. In any case, I have seen examples with the vpn subnet
being permitted and some with it being denied. I think I have tried
it both ways and probably the last way I tried was with it denied.
In any case, the "routing" issue can be reproduced without the
VPN being involved at all. I suspect that the "deny" on the ACL
should actually be "permit" which would fit a definition of:
"allow" any networks here that should not be NAT'd when
remaining "internal" (not going out to the internet).
if the definition is:
"allow" any networks here that should be NAT'd when going
out to the internet.
then they should probably also both be "permit".
It's just not clear to me how this ACL interacts with the
IP NAT INSIDE and IP NAT OUTSIDE directives ....
04-29-2023 11:54 PM
I hope that I can shed some light on this. You say "I must admit that it is not clear to me exactly how that ACL is used.
(or even if it is needed)". That acl is used to define which ip addresses will be translated when they attempt to reach destinations outside and yes it is needed - if you want anyone to have Internet access. As currently configured users in vlan 1010 would have Internet access while users in vlan 1050 would not have Internet access. Not sure if that was intended.
You also say "So it sortta looks like the loopback interface and the 1050 Vlan interface are "isolated" and traffic is not being routed from/to them" It is not that traffic to/from that is not routed but that traffic from them to anything outside is not translated.
You also say "It's just not clear to me how this ACL interacts with theIP NAT INSIDE and IP NAT OUTSIDE directives" ip nat inside defines the interfaces (and therefore subnets) which will be translated when going outside. ip nat outside defines the interfaces where translation will be done. The acl then defines which addresses are to be translated. Remembering that in an acl anything that is not permitted is denied, the result of your current acl is that users in vlan 1010 would have Internet access but users in vlan 1050 would not.
04-30-2023 01:26 PM
Thanks for your comments ...
re:
>I hope that I can shed some light on this. You say "I must admit that it is not clear to me exactly how that ACL is used.
>(or even if it is needed)". That acl is used to define which ip addresses will be translated when they attempt to reach >destinations outside and yes it is needed - if you want anyone to have Internet access. As currently configured users in vlan >1010 would have Internet access while users in vlan 1050 would not have Internet access. Not sure if that was intended.
That does not match my understanding. I think that the ACL defines what traffic will NOT be NAT'd when going
through the tunnel. I'm pretty sure that you could simply have an IP NAT OUTSIDE statement on the outgoing
interface (gi0/0/0) and traffic would get NAT'd just fine without that ACL at all (assuming that the traffic was not going
through the tunnel). You are correct that VLan 1050 traffic was not described in the ACL but my test
of 'ping 10.10.10.102 ingress VLAN1050' should not go through the tunnel or the internet as both
VLAN 1010 and VLAN 1050 are totally "internal".
In any case I have changed the ACL to be:
ip access-list extended 101
10 permit ip any 172.20.1.0 0.0.0.255
20 permit ip 10.0.0.0 0.255.255.255 any
>You also say "So it sortta looks like the loopback interface and the 1050 Vlan interface are "isolated" and traffic is not being >routed from/to them" It is not that traffic to/from that is not routed but that traffic from them to anything outside is not translated.
As stated above, the command 'ping 10.10.10.102 ingress VLAN1050' does not involve the tunnel or in internet or
interfaces that are related to either (so it seems to me that it should work but does not).
04-30-2023 02:21 AM
The NAT is not clear to me' there is two inside one for virtual template and other for vlan ?
Also for virtual template since you use LO as unnumber IP you need to add ip nat inisde under LO not under virtual template.
04-30-2023 01:30 PM
>Also for virtual template since you use LO as unnumber IP you need to add ip nat inisde under LO not under virtual template.
I'm sorry. I don't understand your comment. What is "LO" ? Could you please explain in more detail what you
think is missing? Thanks.
04-30-2023 01:49 PM
You use loopback as unnumbered IP for virtual template' so you need to add ip nat inside under the loopback not direct under virtual template.
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