PDA

View Full Version : DHCP packets dropped after VPN established



nejko
2010-01-22, 09:16
Dear CP users,

we have a problem using DHCP over DHCP relay while IPSec VPN between the gateways is established.

Topology:

User LAN ---- [FW] ==<vpn>== [Core FW] ---- Server LAN

FW is DHCP-relay for User LAN and there is a DHCP server in Server LAN.

If there is no VPN, everything works ok. If I put the FW into the encryption domain, everything works except the dhcp-req-localmodule packets are dropped with error encryption failure: Clear text packet should be encrypted.

Information about the packet:

Src: none (L2 packet)
Dst: 255.255.255.255
Service: dhcp-req-localmodule (67)
Protocol: UDP
Interface: Internal.701 (vlan interface)
Source port: dhcp-rep-localmodule (68)

What should I do so that FW will allow this packet?

The funny thing is, that bootp packets are accepted and encrypted, example of one such packet:

Src: 10.x.x.51
Dst: 255.255.255.255
Service: bootp (67)
Protocol: UDP
Interface: Internal.701
Source port: dhcp-rep-localmodule (68)

So the only difference here is the source IP address and service bootp instead of dhcp-req-localmodule. However, I don't understand why bootp is chosen in this case as the source and destination port numbers are the same in both cases.

Any ideas?

Thanks,
Nejc

nejko
2010-01-25, 06:06
Dear forum users,

I have discovered what causes my problem. It is the "VPN routing" setting in the VPN community properties. If I configure the routing "To center, or through the center to other satellites, to internet and other VPN targets", I can reproduce the problem in my test environment. Looks like that if this option is set, Check Point expects already encrypted DHCP discover packet coming to its internal interface. Which doesn't make sense I guess.

If I configure the VPN routing "To center and to other satellites through center", then DHCP works beautifully. But then not all traffic between the gateways is encrypted, which is not what I want.

So still, does anybody know how to solve this issue?

Thanks,
Nejc

serlud
2010-03-12, 10:37
Dear forum users,

I have discovered what causes my problem. It is the "VPN routing" setting in the VPN community properties. If I configure the routing "To center, or through the center to other satellites, to internet and other VPN targets", I can reproduce the problem in my test environment. Looks like that if this option is set, Check Point expects already encrypted DHCP discover packet coming to its internal interface. Which doesn't make sense I guess.

If I configure the VPN routing "To center and to other satellites through center", then DHCP works beautifully. But then not all traffic between the gateways is encrypted, which is not what I want.

So still, does anybody know how to solve this issue?

Thanks,
Nejc

Thanks.

we have the same issue after replacing VPN-1 Edge (due to performance problem 0,5 Mb/s max with VPN) with UTM-1 132. DHCP do not work any more.

CP do not known about this issues for R65 , R70, R70.1, R70.2 (probably every one already used an Cisco ASA 55xx for all remote offices, we are goint to replace all our VPN-1 Edges within next 2 years with ASA 5505 Clusters, or ASA 5510 Clusters just due to a very high price per Mb/s VPN-1 Edge Unlimited $2000 for 0.5 Mb/s VPN, not nat, simple FW rules -compare with ASA 5505 about $1000 for REAL 80 Mb/s VPN

we have open an Critical SR to be sure this issue will be resolved in short time.
12-Mrz-2010 10:10 open SR
12-Mrz-2010 13:52 After 3.5 hours talking with CP , CP will try to replicate this issue with international TAC. it will take about 1 day (we will see).
15-Mrz-2010 Escalate throu CP Rep.
15-Mrz-2010 11:11 All debugs for replicatable issue has been uploaded to CP.

serlud
2010-03-21, 15:48
Thanks.

we have the same issue after replacing VPN-1 Edge (due to performance problem 0,5 Mb/s max with VPN) with UTM-1 132. DHCP do not work any more.

CP do not known about this issues for R65 , R70, R70.1, R70.2 (probably every one already used an Cisco ASA 55xx for all remote offices, we are goint to replace all our VPN-1 Edges within next 2 years with ASA 5505 Clusters, or ASA 5510 Clusters just due to a very high price per Mb/s VPN-1 Edge Unlimited $2000 for 0.5 Mb/s VPN, not nat, simple FW rules -compare with ASA 5505 about $1000 for REAL 80 Mb/s VPN

we have open an Critical SR to be sure this issue will be resolved in short time. (in our prod. env)
12-Mrz-2010 10:10 open SR
12-Mrz-2010 13:52 After 3.5 hours talking with CP , CP will try to replicate this issue with international TAC. it will take about 1 day (we will see).
15-Mrz-2010 Escalate throu CP Rep.
15-Mrz-2010 11:11 All debugs for replicatable issue has been uploaded to CP.
19-Mrz-2010 CP Rep provide as with *solution* to use an UTM-1 132 as DHCP server -> Rejected due to CP DHCP server known limitation and Customer bussiness needs for Central DNS/DHCP services. We have ask CP Rep again about confirmation that is a Software BUG , but still do not have this comfirmation.....
21-Mrz-2010 CP could not open an 7-zip archive files with all debugs and fw monitors , which we have send on 15-Mrz
22-Mrz-2010 We have upload instaction how to use 7-zip archive manager. We have again an remote session with CP , after 2,6 hours they giving up with *configuration* problem and put the SR to escalation team (which probably has direct assess to R&D. We have again explain an issue to 3nd team. We hope it will be last one and CP will start work on *solution* or BUG resolving.
24-Mrz-2010 CP again provide us with not working sollutiion: It seems to be configuration problem, Please change an VPN Domain on FW from *Based on Topology* to *Manully define*...So it seems that currently the network is not a part of UTM's encryption domain and this should be fixed.
We have also found second Software BUG :
Address spoofing do not work propperly (if destination IP is 255.255.255.255, DHCP Relay is on , VPN Routing 3nd option ) for on affected firewall
We still do not have an answer for following question:
1. Have you manage to replicate our issue in your test lab?
2. Please confirm that this issue is software BUG.
3. It will be great to get both issues (DCHP Relay and Address spoofing BUGS) resolved with the same SR.
Again an Remote session with Eng and R&D to undrestand an issue an check configuration. We have provide an debug for good VPN routing (2nd options in Community To center, or through the center to other satellites)
25-Mrz-2010 CP confirm that VPN routing do not work for dest. 255.255.255.255 with VPN routing 3nd options (To center, or through the center
to other satellites, to internet and other VPN targets) and will provide us with hotfix for this issue as soon as possible.
We have got an half working workaround from CP.
26-Mrz-2010 We have found a full workaround (our case, 1 Cluster NGX-Central R65 , 1 UTM-1 132 R70.1 and 5 Edges -Satelites 8.x.x)
you should manualy define an VPN domain Group and add to this group network range 0.0.0.0 to 0.0.0.0 and network range 255.255.255.255 to 255.255.255.255 and install policy --this will prevent an satelity GW to make VPN routing to Cenral if source IP is 0.0.0.0 and destination 255.255.255.255 (first discovery DCHP packate) (SR change to high )
29-Mrz-2010 According to CP hotfix (for UTM-1 - R70.1 with fifo...hf...) is ready , they making some code review and Q&A test now.
01-Apr-2010 CP update -Still reviewing of code..
10-Apr-2010 we have got an working code.. our case SR: 11-127046971 Our Feedback : negative