Routing With Host /32 Interfaces
Symptom
This document describes a special case of routing involving interfaces that are configured as host /32 links.
- In the scenario below, the firewall has interface ethernet1/1 configured with the address 194.140.4.32/32.
- The firewall has a static default route to the next hop IP that is directly connected on its ethernet1/1 interface: 194.140.4.254.
- The same firewall has an IPsec tunnel to a remote peer 192.168.85.128.234.
admin@PA-440> show interface all
name id speed/duplex/state mac address
--------------------------------------------------------------------------------
ethernet1/1 16 1000/full/up 5c:58:e6:50:96:10
name id vsys zone forwarding tag address
------------------- ----- ---- ---------------- ------------------------ ------ ------------------
ethernet1/1 16 1 L3-Untrust vr:default2 0 194.140.4.32/32
admin@PA-440> show routing route
VIRTUAL ROUTER: default2 (id 2)
==========
destination nexthop metric flags age interface next-AS
0.0.0.0/0 194.140.4.254 10 A S ethernet1/1
194.140.4.32/32 0.0.0.0 0 A H
194.140.4.254/32 194.140.4.254 10 A S ethernet1/1
admin@PA-440> show vpn flow
id name state monitor local-ip peer-ip tunnel-i/f
-- -------------- ----- ------- -------- ------- ----------
1 IPsec1 active up 194.140.4.32 192.168.128.234 tunnel.1
- If the static default route is deleted and replaced with a static route to the destination IP of the remote peer with the same next hop IP, the tunnel goes down after a period of time:
admin@PA-440> show routing route
VIRTUAL ROUTER: default2 (id 2)
==========
destination nexthop metric flags age interface next-AS
192.168.128.234/32 194.140.4.254 10 A S ethernet1/1
194.140.4.32/32 0.0.0.0 0 A H
- As seen in the output below, tunnel monitor transitions to down state and the tunnel later goes into inactive state, indicating that there is no longer transport for IPsec:
admin@PA-440> show vpn flow
id name state monitor local-ip peer-ip tunnel-i/f
-- -------------- ----- ------- -------- ------- ----------
1 IPsec1 inactiv down 194.140.4.32 192.168.128.234 tunnel.1
Reinstating the static default route recovers the tunnel.
Environment
- All PAN-OS versions
- Static Routing
- VM-Series NGFW
- Hardware NGFW
- Layer 2 Forwarding
Cause
Because the host interface does not belong to a broadcast domain (unlike an interface with a lower subnet mask,) a match would have to exist in the routing table for the interesting target including the next hop address. In the scenario above since the static default route, which is a match for all destination IPs without a longer prefix match, has been removed from the routing table the host interface lacks information on how to forward to the next hop address - 194.140.4.254. This is required since the next hop is used for recursion to the destination address.
The problem is evident from the arp cache. Once the static default route is removed and arp entry times out, the firewall is unable to arp for the next hop. The arp entry briefly goes into incomplete and then ages out of the arp table. In other words, the firewall does not send ARP requests for 194.140.4.254 since it does not have a route to this address:
admin@PA-440> show arp ethernet1/1
interface ip address hw address port status ttl
--------------------------------------------------------------------------------
ethernet1/1 194.140.4.254 (incomplete) ethernet1/1 i 1
admin@PA-440> show arp ethernet1/1
interface ip address hw address port status ttl
--------------------------------------------------------------------------------
admin@Lab98-97-PA-440>This results in routing failure since the firewall cannot forward any packets to the next hop device.
Resolution
Configure a static route to next hop should restore routing functionality:
admin@PA-440> show routing route
VIRTUAL ROUTER: default2 (id 2)
==========
destination nexthop metric flags age interface next-AS
192.168.128.234/32 194.140.4.254 10 A S ethernet1/1
194.140.4.32/32 0.0.0.0 0 A H
194.140.4.254/32 194.140.4.254 10 A S ethernet1/1
total routes shown: 3admin@PA-440> show arp ethernet1/1
interface ip address hw address port status ttl
--------------------------------------------------------------------------------
ethernet1/1 194.140.4.254 a4:27:a5:24:4c:13 ethernet1/1 c 33admin@PA-440> show vpn flow 1
id name state monitor local-ip peer-ip tunnel-i/f
-- -------------- ----- ------- -------- ------- ----------
1 IPsec1 active up 194.140.4.32 192.168.128.234 tunnel.1
Additional Information
Depending on the environment and/or topology an alternative solution is to statically configure the ARP entry for the next hop on the host interface. This is not a scalable solution because if the network card on the next hop changes -- for example if that device is replaced, then the entry will need to be updated on the firewall. So for this option, administrative overhead will need to be accounted for.