I have learned, PAN will only build route based and not policy based IPSec tunnels. We need encrypted communication between several Windows Server 2008 systems in the outback and a lot of them in the central office. Till now, we build a site-to-site VPN between the windows server (with the included "extended firewall") and a central Checkpoint system. The remarkable attribute of this VPN is: it encrypts all the routed traffic to the windows server, although the windows server does not have a second ip for the tunnel interface. This seems to be a problem for the Palo Alto system (Nevertheless the PAN lacks the tunnel-ip too). Saying we have a PAN with 192.168.1.1/24 on the internal interface, 172.16.1.1/24 on a dmz-interface and a inner server with 192.168.2.2/24. Behind the PAN is a DMZ-server with 172.16.1.3/24. Behind the windows server is only the local network 192.168.1.0/24, which shall not participate in the tunnel. The tunnel interface at the PAN is 192.168.1.1. It is no problem to put the right proposals to windows and to PAN. The tunnel works fine. Snooping on 172.16.1.3, i can see the icmp-request from 192.168.2.2 (which came out of tunnel). The PAN logges an IKE and an ICMP allow. I see the icmp reply from 172.16.1.3 to 192.168.2.2 too. But the packet dont cross the PAN, and therefore it does not reach his aim 192.168.2.2. I guess, i had to install a static route on the PAN with "192.168.2.2/32 over tunnel.1". But doing so, the IPSec tunnel fails. Perhaps due to the fact, that all packets to 192.168.2.2/32 will be routed through the tunnel, including the "phase 2" packets? Do i have an errror in reasoning? Or is there another possibility for building IPSec tunnel to window server. Client VPN is not an option, because we need the "original" IPs of the server.
... View more