cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1179
Views
5
Helpful
2
Replies

DVTI no ip address?

michel
Level 1
Level 1

Dear experts,

 

I've setup a DVTI with IKEv2 to get remote access into my 2901. However, the IKE session establishes, without any errors, the interface comes up, but no IP address is assigned to the Virtual-access interface. The client is a C881 running IOS 15.5(3)M9, the tunnel terminator is a C2901 running IOS 15.7(3)M8. I can reproduce the problem using an iPhone running the latest iOS as well, which leads me to think the problem is at the tunnel terminator end.

 

After the unit is up, this happens when looking at the Vi3 created:

show ip int vi3
Virtual-Access3 is up, line protocol is up
  Internet protocol processing disabled

If I turn on debugging for CEF drops, I see this when I try to ping from the client:

370833: Jul 25 2021 20:24:52.036 CET: CEF-Drop: Packet from ww.xx.yy.zz (Vi3) to 8.8.8.8, Input feature IP not enabled discard

 

The "failing" Virtual-access interface is:

show derived int vi2
Building configuration...

Derived configuration : 448 bytes
!
interface Virtual-Access2
 ip vrf forwarding lan
 no ip address
 ip unnumbered Loopback0
 ip mtu 1342
 ip nat inside
 ip virtual-reassembly in
 zone-member security lan
 ip tcp adjust-mss 1292
 ospfv3 10 shutdown
 tunnel source <TUNNEL_TERMINATOR_IP>
 tunnel mode ipsec ipv4
 tunnel destination <CLIENT_IP>
 tunnel path-mtu-discovery
 tunnel protection ipsec profile VPNClient-prof
 no tunnel protection ipsec initiate
end

 

My (condensed) config:

aaa authentication login RASLogin group RAS
aaa authorization network RASParam local 
aaa accounting network RASAcct start-stop group RAS

aaa attribute list VPNClient-attr
 attribute type interface-config "ip vrf forwarding lan"
 attribute type interface-config "zone-member security lan"
 attribute type interface-config "ip unnumbered Loopback0"
crypto ikev2 authorization policy VPNClient-pol 
 session-lifetime 3600
 pool VPNIP
 dns <DNSIP>
 wins <WINSIP>
 def-domain <DNSDOMAIN>
 aaa attribute list VPNClient-attr
 route set interface
 route set remote ipv4 0.0.0.0 0.0.0.0
 route set access-list accept-acl4

crypto ikev2 proposal VPNClient-prop 
 encryption aes-cbc-256
 integrity sha256
 group 16
no crypto ikev2 proposal default

crypto ikev2 policy VPN 
 proposal VPNClient-prop
no crypto ikev2 policy default

crypto ikev2 profile VPNClient-ike
 match address local <TUNNEL_TERMINATOR_IP>
 match identity remote any
 identity local dn 
 authentication local rsa-sig
 authentication remote eap query-identity
 pki trustpoint LetsEncrypt
 lifetime 3600
 dpd 600 60 on-demand
 aaa authentication eap RASLogin
 aaa authorization group override eap list RASParam VPNClient-pol
 aaa accounting eap RASAcct
 virtual-template 1

crypto ipsec profile VPNClient-prof
 set security-association lifetime kilobytes disable
 set security-association idle-time 120
 set transform-set VPNClient-trans 
 set ikev2-profile VPNClient-ike
 responder-only

crypto ipsec transform-set VPNClient-trans esp-aes 256 esp-sha256-hmac 
 mode tunnel

interface Loopback0
 ip vrf forwarding lan
 ip address <LOOPBACKIP> 255.255.255.255
 ip nat inside
 ip virtual-reassembly in
 zone-member security lan
 ipv6 address IPV6IP
 ipv6 enable
 ospfv3 10 cost 1
 ospfv3 10 ipv4 area 0
 ospfv3 10 ipv6 area 0

interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip mtu 1342
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1292
 ospfv3 10 shutdown
 tunnel mode ipsec ipv4
 tunnel path-mtu-discovery
 tunnel protection ipsec profile VPNClient-prof

ip local pool VPNIP FIRSTIP LASTIP

ip access-list extended accept-acl4
 permit ip any any

Has any of you experienced this before? What am I doing wrong here?

2 Accepted Solutions

Accepted Solutions

michel
Level 1
Level 1

After looking for a good while I stumbled across the solution yesterday. Apparently, ip unnumbered behaves differently if ipv6 is configured on the Loopback0 interface. I moved all IPv6 configuration to Loopback1 and have seen traffic flowing after this.


I’m wondering, is this a caveat of sorts?

View solution in original post

More to update -

I redid the configuration on the router over the weekend to clean it up, and discovered that the setting

service-routing mdns-sd
source-interface Loopback0

Caused the misbehaviour. It also triggered issues with my Ethernet interfaces not being able to obtain addresses via DHCP. Not sure why or how, but removing the source-interface statement fixed it.

Possibly I stumbled into a bug somehow.

 

View solution in original post

2 Replies 2

michel
Level 1
Level 1

After looking for a good while I stumbled across the solution yesterday. Apparently, ip unnumbered behaves differently if ipv6 is configured on the Loopback0 interface. I moved all IPv6 configuration to Loopback1 and have seen traffic flowing after this.


I’m wondering, is this a caveat of sorts?

More to update -

I redid the configuration on the router over the weekend to clean it up, and discovered that the setting

service-routing mdns-sd
source-interface Loopback0

Caused the misbehaviour. It also triggered issues with my Ethernet interfaces not being able to obtain addresses via DHCP. Not sure why or how, but removing the source-interface statement fixed it.

Possibly I stumbled into a bug somehow.