1. Home
  2. Networking Firewalls
  3. Checkpoint Firewall - "out of state" packets causing isolated email delivery errors???

Checkpoint Firewall - "out of state" packets causing isolated email delivery errors???

I have an issue that I'm really hoping someone knows about.

We had an old Exchange 2000 server that was failing with a internal IP of 192.168.1.2, set up with static NAT on Checkpoint FW-1 NG FP3. When I set up our new Exchange 2003 server on new hardware, I gave it an internal IP of 192.168.1.4 so that it could co-exist with the old server while the config was moved over, and a new anti-spam tested for a month or so. I then went on the checkpoint server and changed the IP address ending in the 2 to a 4 on the node that represents the internal half of the static NAT.

Incoming mail works fine, internal mail works fine, 90% of the outgoing mail reaches it's destination quickly. 10% of the mail doesn't reach certain clients on the outside.

Tracing this, I find that the mail leaves our network, reaches the destination mail server, then times out, comes back and sits in our queue for a retry.

I tried everything from an Exchange/SMTP point of view, but everything checked out. I then activated the second NIC in the mail server and unplugged the Checkpoint Firewall from the network, and assigned the outside NAT address of 207.x.x.163 to the 2nd NIC card of the new Exchange server, and rebooted. After this ALL mail flows fine (without the firewall).

When I talked to the client we had a problem sending mail to, he observed that we were sending a lot of "out of state" packets coming into his Checkpoint Firewall. His systems were in turn sending "out of state" packets back. I figure this was his anti-spam requesting some data from our mail server.

We have this problem with about 5 companies so far, including anyone at a hotmail address.

Why is the firewall doing this? Is there any way to fix the out of state packet problem?

Cheers,

Brad

Reply to
bhodgins
Loading thread data ...

The entire 'mail' leaves the network or the just part of the 3 way handshake ?

Mail does not 'come back'. it either gets delivered or it doesnt.

Have you sniffed the traffic on the wire as it leaves your network ?

He's taking rubbish, no firewall I know of, sends 'out of state' packets anywhere. Let alone back to the source.

Is he running some form of anti spam black holing ?

1st question, have you checked *your* logs for inbound connections on 113/tcp from the remote mail server during the outbound mail session. 2nd question, are you sending back an RST for all connections to 113/tcp rather than just ignoring it all together ?

greg

Reply to
Greg Hennessy

His terminology is wrong, it's not rubbish: Checkpoint will log a packet as "out of state" if it receives an ACK packet with no corresponding entry in the Checkpoint FW-1 state table. It not sending "out of state" simply logging it as such. This means the connection is not being established correctly, somewhere along the way the SYN, SYN-ACK is not being received, or it is timing out. By default Checkpoint allows 25 seconds for the 3 way handshake.

Wayne McGlinn Brisbane, Oz

Reply to
Wayne

May I suggest a walk through phoneboys mailing list archives before expounding on the subject of grandmothers and egg sucking. ;-)

greg

Reply to
Greg Hennessy

Red herring. The out of state packets were not the issue at all. I brought the old server online (the old failing Exchange 2000) and added a connector that would redirect the emails that were failing to the old server whick would send out by DNS. I then discovered that mail was getting stuck in the queue going to the old server. I then realized that I had an internal mail problems as well. Turning on SMTP logging once again, and sending an email to a test mailbox on the old server, I saw the "504+Need+to+authenticate+first". I remember rreading that Symantec A/V could be the cause of this problem. Symantec AV Corp V9, which was set up to guard the local file system, was the culprit. It had email realtime protection turned on by default. Disabling that and restarting the SMTP service, emptied the queues to their respective destinations. We have not had a problem since.

Cheers,

Brad

Reply to
bhodgins

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.