07-25-2021 11:45 AM - edited 12-30-2021 02:05 AM
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?
Solved! Go to Solution.
12-30-2021 01:57 AM
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?
01-13-2023 05:58 AM
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.
12-30-2021 01:57 AM
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?
01-13-2023 05:58 AM
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.
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