error message: syn -> syn-ack -> rst

Hello, I'm trying to establish a tcp 8080 connection from internal to an external host. Initially this worked but after he kept changing his ip (on dhcp) it stooped workin even though I'd reflect the change in the network object for his external pc. It will show green in the logs but this user says he is not recieving anything. I get these error messages as well: error message: syn -> syn-ack -> rst
I also get under the info tab: len 192 or len 48.

This is on a 4.1 firewall.

Thanks

Not sure about the rest of your problem but the Syn->SynAck->Rst sequence is the classic result of trying to reach a port on a remote system when that port is not open or listening. Could be that either you're not reaching the target system that you think you are, or should be reaching, or that you are reaching the correct system but the port you're going for isn't open

If the system you were trying to reach wasn't listening on the port you were requesting, you would never get a syn/ack back. The RST is actually coming from the originator of the connection, not the server. So the conversation goes:

Client: Hello on 8080 (syn)
Server: Yes, 8080 is open (syn/ack)
Client: I don't want to talk to you, goodbye. (rst)

Those 'len 192 len 48' messages are just telling you the packet length - nothing to worry about.

You don't specifically say, but I'm assuming your running Checkpoint FW-1 4.1. What service pack (if any)? Are you running SYNDefender? Are those syn/synack/rst logs from the same connection attempt this client is trying to make, or do they just appear here and there? Are you seeing any "Unknown established TCP Packet" errors? Can this same internal client get to any other site?

I know you said this connection used to work, so I'm not sure why it wouldn't anymore, even with the changing of the IP address. You might want to think about running a tcpdump on the firewall and capture that traffic to analyze in Ethereal. The only real thing I've heard about syn > syn/ack > rst relates to stealth syn port scans or rst attacks to kill someone elses connection, but that usually results in many rst packets being sent, not just one.

Also, what OS is the client running, and exactly what type of traffic are you trying to pass?

You're right of course tiamat. What was I thinking when I wrote that last post - nothing probably. Think I'll go away and shoot myself...

I'm running Checkpoint FW-1 4.1. and I am running SYNDefender in passive mode (when I switched SYNDefender off we still couldn't connect) The client is on XP Pro. The syn/synack/rst logs are from the same client and there are no "Unknown established TCP Packet" errors. This client is external so although he can come in through SecuRemote, in order to have traffic initiated to him from our server on port 8080 we have had to go via external ips (from some strange reason I cannot originate traffic from within the encryption domain to securemote clients - hence we were going via external ips)

Thanks.

wait, now i'm confused. The client is coming in via Securemote? that adds quite a bit to the mix. What build of SR is he running? using IKE or FWZ? UDP encapsulation? is he behind a natting router? Actually, once a securemote user establishes a connection to a host within the encryption domain, that same host can initiate connections back to the securemote host - a guy at work here used to connect to his home machine that way all the time.

Anyway, more questions; can the securemote host connect to any other hosts in the ED? is there any chance you can upgrade to NG? I dont really understand when you say you had to go via external IPs.

As for Checkpoint, this is all they really have to say about seeing syn -> synack -> rst logs:

Solution ID: 36.0.216371.2474844
SYN-->SYN-ACK-->RST:
A client sent a SYN (possibly with a spoofed source address). The
SYN+ACK packet elicited a RST. This usually indicates either a SYN
flood spoofed to appear as coming from a real (but unrelated) computer, or
a port scan using the "Stealth SYN" method. No further actions are
taken by the VPN-1/FireWall-1, as the RST received from the client will close the half-open connection on the server.

Either way, I still think getting a tcpdump on the firewall while he's trying to connect is going to be your best bet to figuring this out. What OS is the firewall running?