[vpn-help] Shrew DHCP over IPSec issue identified

[Alexis La Goutte]

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)
<mayer at lgsinnovations.com> 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
> vpn-help at lists.shrew.net
> https://lists.shrew.net/mailman/listinfo/vpn-help
>