- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- Office mode DHCP method failure
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Office mode DHCP method failure
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.
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In case anyone else has this problem, I ended up fixing it in my lab by having to add below route. This part is actually 100% IMPORTANT, that was sadly missing.
Andy
-
In Virtual IP address for DHCP server replies, enter an IP address from the sub network of the IP addresses which are designated for Office Mode usage.
Office Mode supports DHCP Relay method for IP assignment, so you can direct the DHCP server as to where to send its replies. The routing on the DHCP server and that of internal routers must be adjusted so that packets from the DHCP server to this address are routed through the Security Gateway.
For the context, my lab dhcp server is 172.16.10.199 and gw IP is 172.16.10.253
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andy,
As I see everybody is in Vienn on CPX25 🙂
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Been some time since I been there 😉
Hope everyone is well brother.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
https://support.checkpoint.com/results/sk/sk116957 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, will check the scenarios later.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Guenther,
Just went through all the steps, but none of them really apply to R82.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I also tried adding specific mac address of the machine I was connecting from in allow list on dhcp server, same issue.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Appears issue is in dhcp server end, though I followed exact guide how to set it up.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The same as it ever was...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 🙌
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad you asked because thats EXCATLY what I see, 0.0.0.0 instead of actual right IP. Attached the screenshot.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Had remote with TAC, but sadly, not much progress. I will talk to one of my colelagues to see if we can make this work in the lab.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anything in the Windows event log for the DHCP server? Do you have all of this connected to a LAN switch with DHCP snooping enabled by chance? If you do, you need to disable Option 82 ("information" option) handling.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good point...will check for windows logs.
Andy
