Shrew 2.2.2 / Windows 7 / DHCP over IPSec to Fortigate Problem:
My company is considering using Shrew as its VPN client. For that to be viable, we need it to properly support DHCP over IPSec. However, using Shrew to connect to our Fortigate (FortiOS 5.0.9) firewall/vpn server using the DHCP over IPSEC feature fails. The Fortigate, in this case, is NOT the actual DHCP server. But rather it is configured to be a DHCP relay server. When the Fortigate receives the DHCP discover packet from the client, it relays it to the actually DHCP server. This part works for both Shrew and FortiClient. In the case of a request originating from the Shrew client however, the DHCP server does not respond to the request. With the help of Fortinet engineers, we have determined the issue to be caused by the nature of the discover packet sent by Shrew client to the Fortigate. To our understanding, * Client originated DHCP discover packets should be from (client) port 68 to (broadcast) port 67, whereas * Relayed DHCP discover packets should be from (relay server) port 67 to (unicast dhcp server) port 67. When connecting with FortiClient, the client originated DHCP discover packet is, as described above, a broadcast from port 68 to port 67. Capture of inbound DHCP Discover from client to Fortigate during FortiClient connection (using Fortigate "diag snif" CLI command): In: 172.16.254.75.68 -> 255.255.255.255.67: udp 300 However, when connecting with Shrew from the same client, the client originated DHCP discover packet is a unicast from port 67 to port 67. Capture of inbound DHCP Discover from client to Fortigate during Shrew connection attempt (using Fortigate "diag snif" CLI command): In: 172.16.254.75.67 -> 63.149.110.40.67: udp 253 It is as if the Shrew client is, itself, trying to be a DHCP relay server and assuming the tunnel endpoint (the Fortigate in this case) is the actual DHCP server. In either case, the Fortigate relays the request to the DHCP server. In the case of FortiClient connection, the DHCP Discover packet relayed by the Fortigate has the "Relay Agent IP Address" field in the bootp section set to the properly scoped Fortigate LAN facing IP address. Whereas in the case of a Shrew client connection attempt, the "Relay Agent IP Address" field is set to the client PC's IP address (172.16.254.111) - which will never be properly scoped. Hence the actual DHCP server does not reply. Because of the format of the client DHCP discover packet (unicast 67 to 67), the Fortigate assumes the client is actually a relay server itself, and therefore leaves/sets the relay agent to the client's address. Fragment from Wireshark capture of DHCP discover packet relayed by the Fortigate during a FortiClient connection attempt: Relay agent IP address: 135.22.247.253 (135.22.247.253) Fragment from Wireshark capture of DHCP discover packet relayed by the Fortigate during Shrew connection attempt: Relay agent IP address: 172.16.254.75 (172.16.254.75) My thought is that the DHCP packet sent from the Shrew client should properly be a broadcast from port 68 to port 67. The Fortigate would then properly set the Relay agent IP address to its own address as it does in the FortiClient case. More detailed information (actual capture and debug logs) are available upon request. Please advise. Thanks Rich Mayer LGS Innovations 336-279-3158
_______________________________________________ vpn-help mailing list [email protected] https://lists.shrew.net/mailman/listinfo/vpn-help
