Thread: [Ipsec-tools-devel] IPsec and DHCP on same server
Brought to you by:
mit_warlord,
netbsd
From: Markus <kd...@3d...> - 2006-01-17 14:07:34
|
Hello, I am trying to set up a server offering IPsec as well as DHCP on the same machine. The problem that I am having is that sometimes when a machine requests an IP address via DHCP, IPsec will try to set up a tunnel first. This is nonsense obviously, as the recipient will not be known yet using an IP address. For that reason, I tried excluding ports relevant to DHCP from IPsec using setkey policies. E.g. spdadd 0.0.0.0[68] 192.168.0.0/0 any -P in prio 10 none; spdadd 192.168.0.0/16[67] 255.255.255.255 any -P out prio 10 none; However for some reason, my system log on the server often shows this: Jan 17 14:34:52 linux dhcpd: DHCPDISCOVER from 00:0e:35:b1:4f:1e via eth2 Jan 17 14:34:52 linux racoon: INFO: IPsec-SA request for 192.168.2.17 queued due to no phase1 found. Jan 17 14:34:52 linux racoon: INFO: initiate new phase 1 negotiation: 192.168.2.1[500]<=>192.168.2.17[500] Jan 17 14:34:52 linux racoon: INFO: begin Aggressive mode. Jan 17 14:35:23 linux racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 192.168.2.17->192.168.2.1 Jan 17 14:35:23 linux racoon: INFO: delete phase 2 handler. tcpdump on the server shows: 14:34:52.232136 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0e:35:b1:4f:1e, length: 548 14:34:52.245981 arp who-has 192.168.2.17 tell linux.site 14:34:52.814716 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0e:35:b1:4f:1e, length: 548 14:34:52.995935 :: > ff02::1:ffb1:4f1e: icmp6: neighbor sol: who has fe80::20e:35ff:feb1:4f1e 14:34:53.245734 arp who-has 192.168.2.17 tell linux.site 14:34:53.995930 fe80::20e:35ff:feb1:4f1e > ipv6-allrouters: icmp6: router solicitation 14:34:54.245500 arp who-has 192.168.2.17 tell linux.site Actually, while writing this, I noticed that it seems like the address resolution protocol (arp) triggers IPsec as soon as the DHCP server wants to check whether an address is already in use. Does anyone know how to turn off IPsec for arp? Thanks. -- Markus |
From: Brian C. <B.C...@po...> - 2006-01-17 15:07:50
|
On Tue, Jan 17, 2006 at 03:07:16PM +0100, Markus wrote: > For that reason, I tried excluding ports relevant to DHCP from IPsec using > setkey policies. > E.g. > spdadd 0.0.0.0[68] 192.168.0.0/0 any -P in prio 10 none; > spdadd 192.168.0.0/16[67] 255.255.255.255 any -P out prio 10 none; Based on tcpdump, I've found that the initial DHCP exchange looks like this: 0.0.0.0.68 -> 255.255.255.255.67 DISCOVER 255.255.255.255.68 <- serverIP.67 OFFER 0.0.0.0.68 -> 255.255.255.255.67 REQUEST 255.255.255.255.68 <- serverIP.67 ACK Your policy does not allow the initial 0.0.0.0[68] to 255.255.255.255[67] to pass without IPSEC. A subsequent lease renewal looks like this: clientIP.68 -> serverIP.67 REQUEST clientIP.68 <- serverIP.67 ACK As long as both client and DHCP server implement IPSEC transport then the DHCP exchange will be protected by it. Otherwise you'll need an exemption for that too. > Actually, while writing this, I noticed that it seems like the address > resolution protocol (arp) triggers IPsec as soon as the DHCP server wants to > check whether an address is already in use. IPSEC can only protect IP packets, and ARP is a different protocol than IP, so your ARP requests and responses will always be in the clear. Regards, Brian. |
From: Markus <kd...@3d...> - 2006-01-23 19:25:53
|
On Tuesday 17 January 2006 16:07, Brian Candler wrote: > Based on tcpdump, I've found that the initial DHCP exchange looks like > this: > > 0.0.0.0.68 -> 255.255.255.255.67 DISCOVER > 255.255.255.255.68 <- serverIP.67 OFFER > 0.0.0.0.68 -> 255.255.255.255.67 REQUEST > 255.255.255.255.68 <- serverIP.67 ACK > > Your policy does not allow the initial 0.0.0.0[68] to 255.255.255.255[67] > to pass without IPSEC. I've tested the new rules over the past days and that seemed to have been the problem. Thanks! -- Markus |