Office mode DHCP method failure

[the_rock]

Hey guys,

Just wondering if there might be something simple missing for office mode failing with dhcp server method ip allocation. We even replicated this in the lab (on R82 mind you), though customer is on R81.20 jumbo 92. 

We followed below steps, but no luck.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_RemoteAccessVPN_AdminGuide/Topics-...

When we try in the lab, it simply says "Connection failed. you cannot receive office mode IP address at this time, try to connect again"

There is an sk on support site about this exact error, but all it says its fixed in certain versions, which customer is on anyway.

Any clue what might be the fix? I even verified the connection in the lab back and forth from dhcp server, tried different VIP, no joy.

Tx as always! I attached some screenshots for this as well.

Andy

[AkosBakos]

Hi Andy,

As I see everybody is in Vienn on  CPX25 🙂

Akos

[the_rock]

Been some time since I been there 😉

Hope everyone is well brother.

Andy

[the_rock]

I did also try below things:

-rebooted the fw

-deleted/re-created the site

-completely reconfigured vpn blade from scratch

For what its worth, though not sure it would matter much here, my lab is R82 standalone, but customer has R81.20 distributed environment (mgmt + clusterXL)

Andy

[the_rock]

Also, not sure what to make of below logs, as Im simply testing local user, which appears is authenticated, but just cant get an IP address. I may do some captures on the dhcp server tomorrow and see why that is...

Andy

**********************************

[Expert@R82:0]# vpn debug trunc
[Expert@R82:0]# vpn debug ikeon
[Expert@R82:0]# vpn debug ikeoff
[Expert@R82:0]# grep -i andy $FWDIR/log/vpnd*
[Expert@R82:0]# grep -i andy $FWDIR/log/ike*
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:02] fetch_user_wrapper_cb: got cached username: andy, going to check object is still the same
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:02] GetUserCnFromDn:: illegal DN given as user name andy
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:02][tunnel] IkeSAFromState: User andy saved
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:02][tunnel] InitXAuthSendLast: Message: User andy authenticated by FireWall-1 authentication
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:02] fetch_user_wrapper_cb: got cached username: andy, going to check object is still the same
/opt/CPsuite-R82/fw1/log/iked2.elg:[iked2 16955 4072612352]@R82[5 Feb 22:55:07][tunnel] dhcp_bind_callback: Could not bind an IP address for user andy
[Expert@R82:0]#

[G_W_Albrecht]

https://support.checkpoint.com/results/sk/sk116957 ?

[the_rock]

Thank you, will check the scenarios later.

Andy

[the_rock]

Hey Guenther,

Just went through all the steps, but none of them really apply to R82.

Andy

[the_rock]

I also tried adding specific mac address of the machine I was connecting from in allow list on dhcp server, same issue.

Andy

[the_rock]

Appears issue is in dhcp server end, though I followed exact guide how to set it up.

Andy

[G_W_Albrecht]

The same as it ever was...

[the_rock]

I hear ya, I just cant figure out why its failing. Customer gets exact same error and they even verified with MS support its 100% configured right.

O well, it is what it is I guess...we will open TAC case about it and I will report on results. If we can get it working in R82 lab, I would be very happy with that.

Thanks brother.

Andy

[the_rock · Accepted solution]

I am fairly positive at this point issue is with DHCP server, as we never see any replies when I run tcpdump from the firewall. Im just not sure what is missing, but we will work with TAC to see if we can figure it out.

Best,

Andy

[the_rock]

Hey guys,

Just to give quick update on this...we have call with TAC today to see if we can fix this issue in my R82 lab. I will provide feedback once we speak to an engineer.

Andy

[the_rock]

Hey everyone,

Just to provide another update on this. I worked with TAC and while I agree with them 100% that we dont have proof it is the fw issue, I still find it odd we have exact same problem in the lab, and customer's DHCP server works for everything, EXCEPT dhcp office mode.

3 questions...

1) What should VIP be in gateway properties office mode dhcp settings? Is it an IP from the assigned dhcp scope?

2) Can dhcp scope be from same subnet as LAN or does it have to be something else?

3) Should dhcp scope need to be configured anywhere else in smart console apart from being allowed in the rulebase?

@PhoneBoy @Duane_Toler @AkosBakos 

You guys always respond with awesome ideas/suggestions, so looking forward to your response(s) 🙂

Tx as always.

Andy

[Duane_Toler]

The DHCP scope on the server be for the office mode range you want to hand out (of course, duh!), but the virtual IP address has to be part of that (after all, this is just DHCP/BOOTP relay).  If not, then the server will just ignore the request.  This should NOT be a cluster interface VIP, of course.  Nor should Gaia have its own bootp relay, or dhcp server, configured for this network/interface.  That would risk having ROUTED eat the packets.

That virtual IP address needs to route from the DHCP server back to the cluster as well (probably also "duh"), just like all office mode packets.  Make sure the gateway is also reaching the DHCP server via the interface you expected (static-route in CLISH if necessary). 

If you saw UDP dst port 67 packets go toward the DHCP server, but no replies back, then the DHCP server is misconfigured (bad/non-existant scope), or has no suitable route back.  Worst case, the firewall policy is blocking DHCP relay replies.

[the_rock]

Let me give you the lab scenario:

R82 standalone - 172.16.10.253

dhcp server, windows 2022 server - 172.16.10.199

i tried dhcp scope as 172.16.10.240-254

assigned 172.16.10.245 as dhcp reservation for my PC after running vpn macutil andy (andy is my local vpn username in smart console) and I made reservation based on mac that came up

VIP 172.16.10.254

I dont know if that makes sense at all, but when TAC was on the phone, they verified everything and they even had me try with totally different subnet and it was exactly the same result.

Now that I think about it, though I can ping firewall from the dhcp server itself, so no issues there, but you made me wonder if it could be a route back...hm.

Andy

Thoughts @Duane_Toler ?

Tx as always man for your insights, always super helpful 🙌

[Duane_Toler]

Are you trying to do office mode assignment to the same network where the cluster VIP and interfaces reside?  Or did you mean "VIP" as the virtual IP of the DHCP request?.  I ask because your earlier screenshot showed 172.16.10.201 as the DHCP virtual address, but here you have 172.16.10.254.  Not sure which is which.  If you are trying to do office mode DHCP for the same local LAN, there's no way this is going to work.  I would expect the office mode DHCP pool needs to be a different network (maybe try 172.31.0.0/24, virtual address 172.31.0.1, scope range 172.31.0.100-254).

As for packet flow, if the server is on the same local LAN as the gateway, and you are certain you see packets going to the server, but the server isn't replying, then check the Windows server firewall config to make sure it's allowing DHCP requests inbound.

[the_rock]

Yep, thats exactly what I was trying to do. I know my screenshot showed the IP you mentioned, but then I changed it few times from the scope range, but no luck. Let me try what you suggested tomorrow in the lab and I will let you know if any luck.

Tx again!

Andy

[the_rock]

Just tested, same issue. I will double check on windows server side, but Im 99.99% sure there is nothing there that would be blocking this, since we even turned off windows fw and no other AV software running on it.

Andy

[Duane_Toler]

Hm. You changed the subnet, scope, and virtual address?  Next item is to do tcpdump on the gateway and maybe a quick zdebug to see if the DHCP packets are getting eaten somewhere.   There's also a Global Properties item for the implied rules that allows DHCP for office mode.  Check that, too.

[the_rock]

Yep, changed VIP to exactly what you mentioned, 172.31.0.1 and scope 172.31.0.100-254. Deleted/re-created the site, exact same error, allocation failure. Did tcpdump, only see one dhcp discover packet, thats it.

Andy

[Duane_Toler]

But no reply from the server?  Interesting... feels like the server isn't responding (or isn't getting the request).  Was that a targeted DHCP discover (destination host 172.16.10.199, not destination IP 0.0.0.0) and port 67?

In this small network lab, I presume the firewall is the default gateway for the server (such that packets route back to the gateway implicitly)?  Or is there some other next-hop address?  I know you could ping the server from the firewall, but that's unicast out the nearest-facing interface (local LAN at that point), not sourcing from the virtual IP relay interface.

[the_rock]

Glad you asked because thats EXCATLY what I see, 0.0.0.0 instead of actual right IP. Attached the screenshot.

Andy

[Duane_Toler]

Ah.  The IP layer above that shows the destination IP is indeed 172.16.10.199 as it should be.  That's what I was wondering about.  

The Ethernet frame MAC addresses, however, are the same for source and destination.  The destination MAC address should be the server's MAC address (since the gateway and the server are on the same local LAN).  This could be your issue.  The ethernet frame isn't getting where it needs to go.

[the_rock]

I followed an official doc I referenced in the post and even made dhcp reservation for the mac showing when you run vpn macutil andy command on the R82 gw in the lab. Maybe will remove that and try again.

Andy

[the_rock]

Hey @Duane_Toler 

I want to thank you again for all your help with this, I greatly appreciate it man. Btw, we have RS with TAC tomorrow, so lets see if we can fix it. I feel like I tried everything at this point, but lets see if they can spot something thats "missing".

I will update after I speak with them.

Cheers,

Andy