IPSec Tunnel to Windows Server

[mhuels]

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.

[pkruse]

This is an interesting request but without a client on the windows server you wont be able to build the tunnel. the configuration your describing would not be supported on the PAN. The static route you added would cause a circular route and that's why the tunnel goes down.

Sorry.

~Phil

[mhuels]

Tamensi movetur!

The solution is to give a second IP address to the windows server. Windows will allways send the packets with his first IP, so it is possible to put the second ip as an tunnel endpoint. You can now route the first windows ip to the tunnel interface in the PAN.

If do so, windows will - after activating the so called "connection security rule" - route the packets which are defined as "endpoint 2" over the tunnel, but with his first ip as the source.

et voila, it works.

[mharding]

Have you tried using the IPSec policies in the GPO?

http://www.petri.co.il/configuring_ipsec_policies_through_gpo.htm

[mhuels]

No i did not try to build the windows VPN with "Group Policy". Would it change anything?

[mharding]

I guess the real question is, are you trying to protect all the traffic or just certain ports?

[mhuels]

All the traffic to a specific IP net goes through the tunnel, not only some tcp or udp connections.

[mharding]

I wouldn't think it will work with the PAN since it's designed for a site-to-site VPN. There would need to be a concentrator on each end to exchange keys and route the traffic over the tunnel.

Any reason for the tunnel? Seems a bit extreme if the servers are already behind the PAN.

[mhuels]

The windows server stand out of the headquarter in an unsecure area. So we had to ensure, that really the server is the source of the data packet reaching the inner firewall of the headquarter.

It would be a bit oversized to put 1 IP node behind a separate VPN concentrator.

But there is no fundamental difference between a site-to-site and a client-to-site vpn. Basically, you have to circumvent the dumb client, which lacks a second IP.

Btw. it is a recommended procedure in a windows ambience, to span an IPSec tunnel between two servers, which are sharing ressources. The reason is, because of the dynamic port allocation of the server-to-server rpc traffic, without IPSec you would have to allow on your packet filter firewall all tcp ports greater 1023 in both directions (additionally several ports less then 1023, tcp as well as udp).