Skip to main content

IPv6 IPsec VPN Tunnel Palo Alto <-> FortiGate

IPv6 IPsec VPN Tunnel Palo Alto <-> FortiGate
 VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP.
While it was quite easy to bring the tunnel “up”, I had some problems tunneling both Internet Protocols over the single phase 2 session. The reason was some kind of differences within the IPsec tunnel handling between those two firewall vendors. Here are the details along with more than 20 screenshots and some CLI listings.

(Please note that I have many different VPN tutorials on my blog. Have a look at this list to find the appropriate post. This one here focusses on IPv6 tunneling.)

Lab

My lab consists of a Palo Alto Networks PA-200 firewall with PAN-OS 8.0.3, and a Fortinet FortiWiFi 90D with Firmware Version v5.4.5, build1138. I am using some uncommon but highly secure crypto protocols: Diffie-Hellman group 20 (have a look here), AES-256, SHA-512 and a lifetime of 28800 s (IKE) respectively 3600 s (IPsec). The following figure shows the IP addressing scheme. Note that the VPN tunnel is established over IPv6 only while it tunnels IPv6 and legacy IP!

The configuration was almost straightforward. However, it took me a while to understand the handling of the phase 2 sessions: While Palo Alto simply establishes a single phase 2 tunnel and forwards IPv6 as well as IPv4 packets through it, FortiGate needs two different phase 2 tunnels, one for IPv6 and one for IPv4. That is: I configured two Proxy IDs on the Palo as well, one for IPv6 and another for IPv4. Here are some information from Forti that helped me in thinking about several phase 2 settings.

Configuration Palo Alto

The configuration of the Palo firewall consists of the following steps: IKE Gateway, Tunnel Interface, IPsec Tunnel with Proxy IDs for IPv6 and IPv4, static routes for IPv6 and IPv4, dual-stack policies. Here we go:

Configuration FortiGate

Except the tunnel interface (which must not be added separately) and two separate policy sets (since FortiGate has a shit policy design which distinguishes between the Internet Protocols) the config on the FortiGate is very similar: IPsec Tunnel with Gateway, Authentication, Phase 1 Proposal and two Phase 2 Selectors (IPv6 and IPv4), as well as two static routes (IPv6 and IPv4) and four policies (IPv6 and IPv4). Let’s do this:

Monitoring

I had two Ubuntu clients, one behind each firewall. Rather than only pinging I did some file transfers via ssh/scp. Here are some traffic logs from both firewalls:
At the Tunnel Info from Palo Alto you can see the odd behaviour due to the phase 2 tunnel handling. All outgoing packets are sent via the IPv4 tunnel “fg:fg”. The counter for “Pkt Encap” at the IPv6 tunnel “fg:fg6” shows a 0:

On the FortiGate everything seems to be ok. The counters increased for both phase 2 tunnels, i.e., IPv6 and legacy IP.

Here are some CLI outputs from the Palo Alto:
And some CLI outputs from the FortiGate as well:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
fg # get vpn ike gateway pa
 
vd: root/0
name: pa
version: 1
interface: wan1 6
addr: 2003:51:6012::4:500 -> 2003:51:6012::2:500
created: 8512s ago
IKE SA  created: 1/1  established: 1/1  time: 200/200/200 ms
IPsec SA  created: 2/6  established: 2/6  time: 20/105/300 ms
 
  id/spi: 59 e2961aa79220f222/8323b3551b209700
  direction: initiator
  status: established 8512-8512s ago = 200ms
  proposal: aes-256-sha512
  key: 82899d51b5b35217-e3a0138c5952ea5a-4cbb58af1ac66bc9-5cd33e8471f2e976
  lifetime/rekey: 28800/19987
  DPD sent/recv: 00000042/00000b1d
 
fg #
fg #
fg # get vpn ipsec tunnel name pa
 
gateway
  name: 'pa'
  type: route-based
  local-gateway: 2003:51:6012::4:0 (static)
  remote-gateway: 2003:51:6012::2:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 2054  bytes: 410816  errors: 0
  tx  packets: 2064  bytes: 194056  errors: 0
  dpd: on-demand/negotiated  idle: 20000ms  retry: 3  count: 0
  selectors
    name: 'pa'
    auto-negotiate: enable
    mode: tunnel
    src: 0:0.0.0.0/0.0.0.0:0
    dst: 0:0.0.0.0/0.0.0.0:0
    SA
      lifetime/rekey: 3600/2086
      mtu: 1390
      tx-esp-seq: 1
      replay: enabled
      inbound
        spi: 3d713073
        enc:  aes-cb  37254608594da990ec74eaf9462db97685f0a44d98dff69ee1d565267d9d1e3f
        auth: sha512  35445510111d8f6765e63426709da6d5446d03916bbb36a78cf67e5b6e30e1a66467ba55edc0df6815eb501d8380a550fa979d95678a855962b0c4448e5cb23b
      outbound
        spi: c6a6143d
        enc:  aes-cb  e73b0d5bfdfe926e89904732832a5980e626a3392812e00ee7eafef4812459b3
        auth: sha512  965e87be0736d9230c9389159e4c34cf56a4210a64324d92a340284018174def8bacd925b559da5b6d2ec66f630bb95903a8da9491348986ee4eeada0df73438
      NPU acceleration: none
  selectors
    name: 'pa6'
    auto-negotiate: enable
    mode: tunnel
    src: 0:::/0:0
    dst: 0:::/0:0
    SA
      lifetime/rekey: 3600/2090
      mtu: 1390
      tx-esp-seq: 3
      replay: enabled
      inbound
        spi: 3d713074
        enc:  aes-cb  e10afdf36b9f30ff4c396490dd6ad31cca54234d1948a88350b9123ce948dbc4
        auth: sha512  ce443fd244d4096c90ea2f5f87bbdefb0c96e30134a2214bc828526f8b9c604e8cdd504db833f051f3de2b4b87552a97acd892305a855ccdce1902899ab25a39
      outbound
        spi: e970a075
        enc:  aes-cb  6f534425badca8ec4f5a8db390f87ffd55e9a7fda3d11d6ae415a15f0d91b06b
        auth: sha512  221db0397d159adda847605c2f0f1cdb75337ffa3d4289d6268b08953723300c334fef715b899f6e89881da710bf7c8dac65266fac21dc398a8400cca09bf474
      NPU acceleration: none
 
fg #
Labels:

Comments

Post a Comment

Popular posts from this blog

How to modify SSH/HTTP/Telnet time out in Cisco ASA firewall?

How to modify SSH/HTTP/Telnet time out in Cisco ASA firewall? By default tcp idle timeout is 1:0:0 hh:mm:ss. If in case you need to modify it you can do it by MPF (Modular Policy Framework). Let us setup a custom timeout when traffic is coming from particular host 10.77.241.129. !— Match the traffic using the access-list —! object-group service DM_INLINE_TCP_1 tcp port-object eq www port-object eq ssh port-object eq telnet access-list outside_mpc extended permit tcp host 10.77.241.129 <source ip> any object-group DM_INLINE_TCP_1 !— Define the class map Cisco-class –! class-map Cisco-class match access-list outside_mpc !— Call this class-map into policy map and set the connection reset after 10 min when traffic is coming from particular host —! policy-map Cisco-policy class Cisco-class set connection timeout idle 0:10:00 reset !— Apply the policy-map Cisco-policy on the interface. —! service-policy Cisco-polic
Post a Comment
Read more

Configuring Proxy ARP for Manual NAT

Configuring Proxy ARP for Manual NAT Symptoms After creating a Manual Static NAT rule, Security Gateway does not answer the ARP Requests for the Static NATed IP address that was configured in the Manual NAT rule. Security Gateway replies to ARP requests with a wrong MAC address, mostly for the NAT traffic.  Introduction Let us consider the following scenario: Two networks ( Network_A  and  Network_B ) are separated by a Security Gateway (single Security Gateway or ClusterXL). On each network, there is a host ( Host_A  on  Network_A ,  Host_B  on  Network_B ). Let us assume, that  Network_A  represents the  Internal  network, and  Network_B  represents the  External  network. According to the existing standards, when  Host_B  needs to send data to  Host_A , an ARP Request for the MAC address of  Host_A  will be sent by  Host_B  to  Network_B . Since  Host_A  is located on another network, and the Security Gateway acts as a router, this ARP Request (sent
Post a Comment
Read more

Unable to Connect to Server Checkpoint R80

Unable to Connect to Server Checkpoint R80 Unable to Connect to Server A connection to the management server will fail if: A firewall between SmartConsole and the management server blocks Port 19009 -  port 19009 is used for a new R80 service. Allow traffic on this port for all clients and management servers. No GUI clients are assigned -  Open the Gaia Portal. If the First Time Configuration Wizard opens, complete it. If the First Time Configuration Wizard has already run, open  User Management > GUI Clients  and add a client. When using Multi-Domain Security Management, connect SmartConsole to the Multi-Domain Server and make sure the domains have GUI clients assigned to them. The required processes are not reachable -  Make sure the computer with SmartConsole installed can reach the IP address of the management server, and that these server processes are up and running: cpm fwm Operation time out  – Your connection to the management (cloud demo
Post a Comment
Read more