Hi Mayer, Nice analyze !
It is possible to attach your capture and debug logs ? You using Shrew on Windows or Linux ? If you using Linux, you can try to modified directly iked/ike.policy.cpp (line 474) src.port = htons( UDP_PORT_DHCPS ); => src.port = htons( UDP_PORT_DHCPC ); Regards On Thu, Dec 11, 2014 at 7:32 PM, Mayer, Richard S (Rich) <[email protected]> wrote: > 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 > _______________________________________________ vpn-help mailing list [email protected] https://lists.shrew.net/mailman/listinfo/vpn-help
