Of course, you should use dual-stack networks for almost everything on the Internet. Or even better: IPv6-only with DNS64/NAT64 and so on. ;) Unfortunately, still not every site has native IPv6 support. However, we can simply use the IPv6 Tunnel Broker from Hurricane Electric to overcome this time-based issue.
Well, wait… Not when using a Palo Alto Networks firewall which lacks 6in4 tunnel support. Sigh. Here’s my workaround:
Please note that my approach only works when you have at least 2x public IPv4 addresses. This might not be the case on almost all residential ISP connections. :( Since I am using the Palo in my lab which has a couple of public legacy IP addresses, it works quite good. Here is the idea:
- Using a Cisco router for doing the 6in4 tunnel to HE.
- Using 2x “untrust” interfaces on the Palo, one for legacy IP to the Internet, one for IPv6 to the Cisco router. I am using the first routed /64 from HE for this transfer segment between the Palo and the router, while I am routing the other /48 to the Palo. (Note that you get at least 1x /64 and 1x /48 from HE.)
- Since both interfaces are within the same “untrust” zone, your policies are as normal. You don’t have to distinguish between the outgoing interface nor the Internet Protocol. After all!
Here’s a rough sketch:
Cisco Router with 6in4
This is my Cisco router config. I am using a Cisco 2811 (revision 3.0), IOS version 15.1(4)M12a. Probably nothing new for you. Default IPv4 route to the ISP, default IPv6 route into the tunnel, another /48 route to the Palo Alto:
interface Tunnel0 description Hurricane Electric IPv6 Tunnel Broker no ip address ipv6 address 2001:470:1F0A:101A::2/64 ipv6 enable tunnel source 193.24.227.12 tunnel mode ipv6ip tunnel destination 216.66.80.30 ! interface FastEthernet0/0 description ISP ip address 193.24.227.12 255.255.255.224 ! interface FastEthernet0/1 description PA-220-eth1/1 no ip address ipv6 address 2001:470:1F0B:1024::1/64 ipv6 enable ! ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 193.24.227.1 ! ipv6 route 2001:470:765B::/48 FastEthernet0/1 2001:470:1F0B:1024::2 ipv6 route ::/0 Tunnel0
Show of routes:
router1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 193.24.227.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 193.24.227.1, FastEthernet0/0
193.24.227.0/24 is variably subnetted, 2 subnets, 2 masks
C 193.24.227.0/27 is directly connected, FastEthernet0/0
L 193.24.227.12/32 is directly connected, FastEthernet0/0
router1#
router1#show ipv6 route
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via Tunnel0, directly connected
C 2001:470:1F0A:101A::/64 [0/0]
via Tunnel0, directly connected
L 2001:470:1F0A:101A::2/128 [0/0]
via Tunnel0, receive
C 2001:470:1F0B:1024::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:470:1F0B:1024::1/128 [0/0]
via FastEthernet0/1, receive
S 2001:470:765B::/48 [1/0]
via 2001:470:1F0B:1024::2, FastEthernet0/1
L FF00::/8 [0/0]
via Null0, receive
Palo Alto with 2x Untrust Interfaces
I am using a PA-220 with PAN-OS 8.1.7 in this lab. Two hardware layer 3 interfaces, one with IPv4-only directly attached to the ISP, the other one with IPv6-only plugged into the Cisco router. Note that both interfaces are of the same “untrust” security zone:
Default IPv6 route pointing to the Cisco router:
One policy to rule them all:
Likewise, the traffic log shows both Internet Protocols from this single policy:
CLI show of routes:
weberjoh@pa> show routing route
flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2, E:ecmp, M:multicast
VIRTUAL ROUTER: default (id 1)
==========
destination nexthop metric flags age interface next-AS
0.0.0.0/0 193.24.227.1 10 A S ethernet1/1
193.24.227.0/27 193.24.227.9 0 A C ethernet1/1
193.24.227.9/32 0.0.0.0 0 A H
193.24.227.224/27 193.24.227.225 0 A C ethernet1/5.224
193.24.227.225/32 0.0.0.0 0 A H
::/0 2001:470:1f0b:1024::1 10 A S ethernet1/2
2001:470:1f0b:1024::/64 2001:470:1f0b:1024::2 0 A C ethernet1/2
2001:470:1f0b:1024::2/128 :: 0 A H
2001:470:765b::/64 2001:470:765b::1 0 A C ethernet1/5.224
2001:470:765b::1/128 :: 0 A H
total routes shown: 10Ping from the trust interface (selected with its source IPv6 address):
weberjoh@pa> ping inet6 yes source 2001:470:765b::1 host weberblog.net PING weberblog.net(webernetz.net) from 2001:470:765b::1 : 56 data bytes 64 bytes from webernetz.net: icmp_seq=0 ttl=55 time=12.1 ms 64 bytes from webernetz.net: icmp_seq=1 ttl=55 time=5.85 ms 64 bytes from webernetz.net: icmp_seq=2 ttl=55 time=5.90 ms 64 bytes from webernetz.net: icmp_seq=3 ttl=55 time=6.58 ms 64 bytes from webernetz.net: icmp_seq=4 ttl=55 time=5.79 ms ^C --- weberblog.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4043ms rtt min/avg/max/mdev = 5.794/7.252/12.126/2.453 ms, pipe 2
Traceroute. Its “ipv6 yes” rather than “inet6 yes” as of ping. Uh:
weberjoh@pa> traceroute ipv6 yes source 2001:470:765b::1 host weberblog.net traceroute to weberblog.net (2a01:488:42:1000:50ed:8588:8a:c570), 30 hops max, 40 byte packets 1 (2001:470:1f0b:1024::1) 2.255 ms 1.797 ms 2.436 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * ae4.cr-nashira.cgn1.bb.godaddy.com (2a01:488:bb::f2) 5.888 ms 7 ae0.cr-artemis.cgn3.hosteurope.de (2a01:488:bb::a3) 5.665 ms 5.618 ms 5.599 ms 8 2a01:488:42::a1e:1e77 (2a01:488:42::a1e:1e77) 5.578 ms 5.566 ms 5.683 ms 9 webernetz.net (2a01:488:42:1000:50ed:8588:8a:c570) 6.255 ms 6.238 ms 6.187 ms
Works. Good.
Conclusion
Obviously, I am not happy that Palo Alto Networks has not implemented 6in4 tunnels so far. It shouldn’t be that hard.
However, due to the good design of having security zones summing up multiple interfaces, as well as a single security policy set that is able to handle IPv4 and IPv6 traffic, this workaround is feasible.
(Note that on a FortiGate firewall it’s vice versa: They have 6in4 tunnels but distinct security policies – one for v4 and another one for v6. That is: Quite simple to run a tunnel to HE while quite stupid to have different policy sets. In summary, they aren’t better.)
Featured image “255/365 Umleitung – Selzer Kerb vom 12. bis 16. September” by Frank Hamm is licensed under CC BY-NC-ND 2.0.