[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [FW-1] Netbios NAT Issue (bug?) in NG
Hi everyone, We have an NG firewall with three legs, external, internal, and DMZ. Note - All IP's are fudgged. The DMZ leg is in a 192.168.50.x network. Two servers on it, dmz1 (192.168.50.10, Natted to 206.186.27.10) and dmz2 (192.168.50.20, Natted to 206.186.27.20) Internal is 170.153.x.x. External is 206.186.27.x. We've got a few windows boxes in our DMZ and use static nat to nat them. They are visible to the outside world via their natted address. We have a PDC and WINS server in the internal network that the DMZ clients need to talk to for authentication and windows name resolution. The internal (170.153.x.x) clients and servers have routes to get to the DMZ systems via the firewall. They can access the DMZ using the 192.168.50.x addresses. Likewise, the DMZ systems know how to reach the internal systems using 170.153.x.x IP's. We have a rule that says basically Internal, DMZ -> DMZ, Internal : NBT : Accept This allows the DMZ systems to talk netbios type stuff with the PDC, WINS etc. Since we do static nat for the DMZ systems, we configure it on the NAT tab. This would be fine, except that we don't want the DMZ -> Internal and Internal -> DMZ traffic to be natted, since they can all use the real addresses. To fix this, we've got a rule in front of the auto generated rules that says DMZ -> Internal : Original -> Original, and Internal -> DMZ : Original -> Original. This works fine for all packets except when we get into netbios name lookups. Here's the problem - Like I mentioned before, there's an Internal WINS server. When a system on the DMZ, for example dmz1, tries to talk to dmz2 it queries the internal WINS server 170.153.x.x for the IP address of dmz2. The internal WINS server replies with info about dmz2, specifically a netbios name response. We've sniffed it, and can see that the server replies correctly with the IP 192.168.50.20 in the payload. Unfortunately the packet goes through the firewall and it's payload (NOT the IP header, src and dst are untouched) is NATTED! The paylod of the packet is the IP that I use in the automatic NAT rule, not the IP of the server. This is especially bad since I have manual NAT rules above the Auto NAT rules. One solution I found was to re-create the NBT groups services, without the special protocol-type field setting. (Typically, nbname has a protocol type of nbname, I change it to blank.). Any ideas would be welcome. Checkpoint - Can you add this to your bug list? John Delisle Corporate Technology Ceridian Canada Ltd********************************************************************** This e-mail and any files transmitted with it are considered confidential and are intended solely for the use of the individual or entity to whom they are addressed (intended). This communication is subject to agent/client privilege. If you are not the intended recipient (received in error) or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please notify the sender immediately. ********************************************************************** ================================================= To set vacation, Out Of Office, or away messages, send an email to [email protected] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [email protected] =================================================
|