Outgoing TCP connections

[bjbgraphics]

I had a bit of a scare this past weekend when, in my router (D-Link DGL-4300) logs, I noticed a large series of blocked outgoing TCP packets coming from my computer's IP. Each connection tried to use the next sequential port to connect to the IP 80.69.95.148:80 and I feared some malware of some sort was running and was looking for a connection out.

After some investigation I found out that IP is actually the ad server (adlog.cdfreaks.com) for cdfreaks.com and I did happen to have an article on their site open on my computer. What I am not 100% clear of is why my router blocked the outgoing connections.

My theory is that my router's SPI (Stateful Packet Inspection) closed the initial connection used by the site but because I had the article open for so long that the Flash container they use for their ads initiated a new connection back to the ad server. When this new connection got to the router it found no related sessions and thus blocked the attempts.

Does this seem reasonable or is there something more at play? Does anyone else see similar blocked outgoing connections from their network?

BJB

[CrowdAds]

[shaihulud]

If I read the context of the log I could possibly understand it better. But, basically, what you said is correct. SPI checks the packets state from start to finish. If the state is invalid then it will prevent it from ingress and egress.

From what I gather is that your initial connection was made and done with. The possible flash advert was trying to make an invalid connection from your browser or was sending packets that were not stamped with the proper flag(s). Therefore SPI dropped them. As the advert was trying to continue with making an invalid connection or send invalid packets it was consecutively increasing the port as normally done since the previous port was used.

SPI does not close connections it checks the state of connections. Only TCP can close or time out and close the connection. UDP is is connection-less and therefore has different rules which apply to these packets.

[bjbgraphics]

Thanks for the reply shaihulud, and for your explanations. So it would seem that the Flash ad was indeed trying to use a connection that SPI had already considered a closed or invalid state.

Here are some lines from the log:

[INFO] Sat Jan 27 14:31:47 2007 Blocked outgoing TCP packet from 192.168.0.XXX:4027 to 80.69.95.148:80 as FIN:ACK received but there is no active connection
[INFO] Sat Jan 27 14:31:47 2007 Blocked outgoing TCP packet from 192.168.0.XXX:4005 to 80.69.95.148:80 as FIN:ACK received but there is no active connection
[INFO] Sat Jan 27 14:31:46 2007 Blocked outgoing TCP packet from 192.168.0.XXX:4025 to 80.69.95.148:80 as FIN:ACK received but there is no active connection

[...and on through the 84 ports in between...]

[INFO] Sat Jan 27 14:30:59 2007 Blocked outgoing TCP packet from 192.168.0.XXX:3941 to 80.69.95.148:80 as FIN:ACK received but there is no active connection
[INFO] Sat Jan 27 14:30:59 2007 Blocked outgoing TCP packet from 192.168.0.XXX:3943 to 80.69.95.148:80 as FIN:ACK received but there is no active connection
[INFO] Sat Jan 27 14:30:59 2007 Blocked outgoing TCP packet from 192.168.0.XXX:3940 to 80.69.95.148:80 as FIN:ACK received but there is no active connection

BJB

[pointreyes]

Looks like the egress was trying to complete the end of the transmission (FIN flag) but due to not receiving an acknowledgment flag (ACK) that the egress was continual trying until it finally stopped.

[shaihulud]

OK, to what I see is that, as Pointreyes says, there is a final termination but I see incorrect flags to the connection to port 80. With a graceful termination the FIN ACK flags come at the second stage and from the one hosting the services, the server. First, to terminate, you send a FIN flag. The server in response sends and ACK FIN back to the host that used the services. Finally, the host that used the services sends the final terminating FIN flag. I am not taking into consideration the sequential ports with this basic description. However, since you are sending what the SPI firewall considers an invalid combination for termination to the connection it is being dropped. This termination attempt continues with the increase of the sequential ports to use, but is still considered invalid, and will finally time out ungracefully.

IIRC, I think Flash uses a different port. This termination attempt is strictly port 80:HTTP. So I do not entirely think that it [Flash] is the originator of the “problem.” Another reason is due to the DGL-4300's support for RTSP which I do think Flash uses now. With UPnP the appropriate ports will open and close for the RTSP packets.

You can always make a capture of the packets using Packetyzer, the best freeware capture program IMO. It is based on Ethereal, now called Wireshark. I just may do capture too. I am curious myself what is happening. Network Chemistry - The Wireless Security Experts

I just went there for a quick browse and not a single SPI entry was logged. When I have time, and if it happens to me I could post. Oh, do not forget to compare with Active Sessions too. The IP and ports have the basic NAT table for you to compare.

[bjbgraphics]

Thanks for the replies pointreyes and shaihulud.

I have RTSP and UPNP disabled in the router as well as my computer.

Another reason is due to the DGL-4300's support for RTSP which I do think Flash uses now. With UPnP the appropriate ports will open and close for the RTSP packets.

I have also tested, using my Windows Firewall logs capturing all connections, what happens when I go to the site (Exact link: CDFreaks.com | reviews| dvd is not dead) and I saw the same connections but this time the router did not block them.

I just went there for a quick browse and not a single SPI entry was logged.

Have you tried leaving the site open in a browser for an hour or two?

BJB

[shaihulud]

You can still have RTSP toggled to enabled and just have UPnP disabled. Personally, from my really good understanding of TCP/IP, disabling UPnP is not any safer than you making a connection to a server anyways-seriously. Making networking connection, actually networking in general, is intrinsically unsafe.

Maybe it was a fluke of some sort, unsure really. I cannot even begin to speculate for I do not have any of the packets captured for what has taken place to see the origins and the ends of the issue. Windows firewall is not as robust nor is it stateful (It is stateless). So, I do not expect Windows firewall to comprehend the relationships of the packets that the SPI firewall from the ipOS in your DGL-4300 can perform, and even log them.

No, I did not try for a long period of time like you. I just went over and tried to see if I can replicate what you experienced. But I have been to other web sites before and had similar invalidly flagged packets. Basically, IMO, the firewall was doing its job, even if it was to create a problem with the website, for those packets should not have even been placed on the wire in the manner as they were.

My favorite packets to see in the log are fabricated packets. They are invalid in many ways. Not just in the fact that there has been no connection established and invalid flags, but are also in proxy. You will see the packet come from address X and then say there is no connection between Y, not X, for your WAN address. That is a nice knock on the front door. Even some firewalls can be fooled, and obviously have been. TCP can easily be manipulated so as to make a host accept packets. Personally, UDP is the bane of safe networking. But as I said this is how it goes for networking is intrinsically unsafe.

[TCM]

Originally Posted by BJB

Here are some lines from the log:

[INFO] Sat Jan 27 14:31:47 2007 Blocked outgoing TCP packet from 192.168.0.XXX:4027 to 80.69.95.148:80 as FIN:ACK received but there is no active connection

it looks like the packet filter has a lower timeout for connections than the client. the client still had the connection open but no traffic was flowing for a very long time. meanwhile, the packet filter had cleared the state due to timeout when the client finally tried to close the connection.

[shaihulud]

You know TCM, you made me finally read the log statement. I was for some reason thinking the packet was related in an inverse manner, but it obviously is not (duh!). I am very positive that the connection has been terminated in a non-graceful manner. BJB's host computer is now trying to terminate gracefully, but since the connection is no longer present it is invalid and dropped by the SPI egress wise. Just to note, the connection interval given is 7800 seconds TCP, and 300 seconds UDP for the DGL-4300. Also the ipOS, the router's operating system, is GNU based.

[bjbgraphics]

Thanks very much for the analysis TCM and shaihulud. So, the router had closed the initial connections before the client had a chance to close them itself and later when the client attempted to do so the router balked since their were no related connections to close. Seems reasonable.

BJB

[kjetilbm]

Originally Posted by bjbgraphics

Thanks very much for the analysis TCM and shaihulud. So, the router had closed the initial connections before the client had a chance to close them itself and later when the client attempted to do so the router balked since their were no related connections to close. Seems reasonable.

BJB

Have you solved the problem? If you have, what did you do?
I have the same problem with my DLink DIR-635 router, and I'd be very happy for an answer which could end this annoying problem.

[shaihulud]

Basically, this is a common issue of how a browser (and possibly anything else) will terminate the connection(s). It happens a lot and is not an issue. I would not worry about it at all. What it is trying to due to terminate when the connection is not there anymore. Since there is no connection in the NAT table the packet is prevented from passing to the WAN.

[kjetilbm]

But the problem is:
I use to play online games like Live for Speed and Counter Strike, and I use to listen to web radio while playing.
When playing/listening to music, suddenly the music just disappears, and few seconds later, I get kicked from the game server due time out.
About 5-10 seconds after I get kicked from the server, the connection is back; my music starts to play and I can rejoin the servers.

The weirdest thing in this case, is that the router may be working fine for hours without any disconnect, and just suddenly out of the blue, I have disconnecting problems again, and get disconnected all the time. It's about 10 seconds to 30 minuted between the D/C`s.

I've spent some days mailing with DLink now.. I've tried every settings they said I should try, but nothing helps. I called them and got some more settings to try. I tried them too, but they didn't make the router work any better than before. :/

Btw, this problem is on every single PC in the LAN, which contains 4 laptops and 3 non-laptops. The laptops and two of the non-laptops are connected wireless, and the last one is connected with wire. And as I said, every computer in the network has this connection problem, even the one which is connected with wire. (I'm pretty much the one who gets annoyed of this problem, the rest of the family is barely using their connection to easy web surfing, and don't notice any problems, except from that the internet is a bit slow sometimes.


I dont know if this answer were necessary, but this is how my problem is...

Here is a bit of the router log:

[INFO] Sun Feb 08 12:36:30 	Allowed configuration authentication by IP address 192.168.0.xx
[INFO] Sun Feb 08 12:36:27 	Blocked incoming TCP packet from 85.xxx.111.xx:3xxx9 to 88.xx.xx.26:5xxx9 as FIN:PSH:ACK received but there is no active connection
[INFO] Sun Feb 08 12:35:47 	Blocked incoming TCP packet from 85.xxx.111.xx:3xxx2 to 88.xx.xx.26:5xxx9 as FIN:PSH:ACK received but there is no active connection
[INFO] Sun Feb 08 12:35:43 	Blocked incoming ICMP error message (ICMP type 3) from 81.xxx.72.xx to 88.xx.63.xx as there is no TCP connection active between 88.xx.63.xx:3792 and 192.168.1.1xx:2xxx9
[INFO] Sun Feb 08 12:35:40 	Previous message repeated 1 time
[INFO] Sun Feb 08 12:35:34 	UPnP renew entry 255.255.255.255 <-> 88.xx.63.xx:5xxx9 <-> 192.168.0.111:6xx0 UDP timeout:-1 'MsnMsgr (192.168.0.111:6xx0) 5xxx9 UDP'
[INFO] Sun Feb 08 12:35:28 	Blocked incoming TCP packet from 85.xxx.111.xx:3xxx4 to 88.xx.63.xx:5xxx9 as FIN:PSH:ACK received but there is no active connection
[INFO] Sun Feb 08 12:35:28 	Blocked incoming ICMP error message (ICMP type 3) from 85.xxx.199.xxx to 88.xx.63.xx as there is no TCP connection active between 88.xx.63.xx:3xx9 and 192.168.1.1xx:3xxx1
[INFO] Sun Feb 08 12:35:17 	Blocked incoming TCP packet from 85.xxx.111.xx:3xxx4 to 88.xx.63.xx:5xxx9 as FIN:PSH:ACK received but there is no active connection
[INFO] Sun Feb 08 12:34:46 	Blocked incoming TCP packet from 85.xx.21.xxx:6xxx9 to 88.xx.63.x:5xxx9 as FIN:PSH:ACK received but there is no active connection
[INFO] Sun Feb 08 12:34:26 	Blocked incoming ICMP error message (ICMP type 3) from 85.xxx.116.xxx to 88.xx.63.xx as there is no UDP session active between 88.88.63.26:55789 and 192.168.80.xx:xxxx0
[INFO] Sun Feb 08 12:34:19 	Blocked incoming TCP packet from 88.xx.76.xx:5xxx6 to 88.xx.63.xx:5xxx9 as FIN:ACK received but there is no active connection
[INFO] Sun Feb 08 12:33:24 	Blocked incoming TCP connection request from 80.xxx.8.xx:5xxx9 to 88.xx.63.xx:3xx7
[INFO] Sun Feb 08 12:33:13 	Previous message repeated 7 times
[INFO] Sun Feb 08 12:33:12 	Blocked incoming TCP connection request from 80.xxx.8.xx:5xxx2 to 88.xx.63.xx:3xx7
[INFO] Sun Feb 08 12:33:05 	Previous message repeated 6 times
[INFO] Sun Feb 08 12:32:14 	Blocked incoming ICMP error message (ICMP type 3) from 85.xxx.199.xxx to 88.xx.63.xx as there is no TCP connection active between 88.xx.63.xx:3xx8 and 192.168.1.1xx:3xxx1
[INFO] Sun Feb 08 12:32:08 	Blocked incoming TCP packet from 84.xx.175.xxx:6xxx8 to 88.xx.63.xx:5xxx9 as RST:ACK received but there is no active connection
[INFO] Sun Feb 08 12:32:02 	Blocked incoming UDP packet from 136.x.7.xx:1xx6 to 88.xx.63.x:1xx4

[shaihulud]

Are you using dynamic fragmentation and DNS Relay?

[kjetilbm]

Urr..

DNS Relay is enabled
Fragmention Treshold = 2346
RTS Treshold = 2346

I'm sure if that answers your questions, but I'm not really sure about what you are talking about now. I can't say I'm a very advanced user...