Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unknown Outbound Traffic (revisited)

https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32198

Lets try this again...

I am curious about the traffic from IP addresses:
128.242.114.242 (rdns mail2.after.college.com) at NTT America.
218.213.238.228 (no rdns) at HKNET-Hong Kong.
213.198.65.27 (rdns euu0300091-pip.eu.verio.net) NTT/Verio Europe.
69.10.147.66 (rdns unknown.rackforce.com) at RackForce Hosting.

Specifically regarding src port 2080.

src port is always 2080
dst port varies (30000-59999)
all traffic is tcp
The only proxys involved are on/in the ASG box. If any other proxies outside my modem exist I would like to know.

Since from what I have observed, up2date appears to use only ports 443 and 80. Because of this belief, the traffic described herein appears odd to me. 

Does up2date also require port 2080 to function correctly or close a connection? The packet data captured in front of the ASG indicates that the connection is trying to close and is retransmitting. These retransmissions are what the ASG's packet capture feature is logging. I do not know what the standard is for making sure a port is closed, but since the traffic is tcp and not udp I do not believe that 24 packets are required to close a connection. Which is what the ASG logged this morning from 09:38 to 10:00 GMT from IP 128.242.114.242 to two different dst ports (48775 and 37739). Am I wrong about anything I have stated?

Note: I have port 2080 blocked in the packet filter rules (along with many other ports). 

This traffic causes me some anxiety since I do not know the purpose of the traffic's original cause.

Will someone please explain this traffic?

Note: All my log data is sent to both Mynetwatchman and Dshield.

out.


This thread was automatically locked due to age.
  • No.     Time        Source                Destination           Protocol Info
          5 8866.603266 128.121.10.114        24.243.46.239         TCP      [TCP Retransmission] autodesk-nlm > 53563 [ACK] Seq=1 Ack=1 Win=6432 Len=1448 TSV=2519438501 TSER=3478199

    Frame 5 (1514 bytes on wire, 1514 bytes captured)
        Arrival Time: Jan  9, 2009 18:29:59.812417000
        [Time delta from previous captured frame: 119.987534000 seconds]
        [Time delta from previous displayed frame: 119.987534000 seconds]
        [Time since reference or first frame: 8866.603266000 seconds]
        Frame Number: 5
        Frame Length: 1514 bytes
        Capture Length: 1514 bytes
        [Frame is marked: False]
        [Protocols in frame: eth:ip:tcp[:D]ata]
        [Coloring Rule Name: Bad TCP]
        [Coloring Rule String: tcp.analysis.flags]
    Ethernet II, Src: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05), Dst: 3com_ce:ee:01 (00:50:04:ce:ee:01)
        Destination: 3com_ce:ee:01 (00:50:04:ce:ee:01)
            Address: 3com_ce:ee:01 (00:50:04:ce:ee:01)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Source: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05)
            Address: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Type: IP (0x0800)
    Internet Protocol, Src: 128.121.10.114 (128.121.10.114), Dst: 24.243.46.239 (24.243.46.239)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 1500
        Identification: 0xa1f3 (41459)
        Flags: 0x04 (Don't Fragment)
            0... = Reserved bit: Not set
            .1.. = Don't fragment: Set
            ..0. = More fragments: Not set
        Fragment offset: 0
        Time to live: 49
        Protocol: TCP (0x06)
        Header checksum: 0xcf5b [correct]
            [Good: True]
            [Bad : False]
        Source: 128.121.10.114 (128.121.10.114)
        Destination: 24.243.46.239 (24.243.46.239)
    Transmission Control Protocol, Src Port: autodesk-nlm (2080), Dst Port: 53563 (53563), Seq: 1, Ack: 1, Len: 1448
        Source port: autodesk-nlm (2080)
        Destination port: 53563 (53563)
        Sequence number: 1    (relative sequence number)
        [Next sequence number: 1449    (relative sequence number)]
        Acknowledgement number: 1    (relative ack number)
        Header length: 32 bytes
        Flags: 0x10 (ACK)
            0... .... = Congestion Window Reduced (CWR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...1 .... = Acknowledgment: Set
            .... 0... = Push: Not set
            .... .0.. = Reset: Not set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 6432
        Checksum: 0xde56 [correct]
            [Good Checksum: True]
            [Bad Checksum: False]
        Options: (12 bytes)
            NOP
            NOP
            Timestamps: TSval 2519438501, TSecr 3478199
        [SEQ/ACK analysis]
            [TCP Analysis Flags]
                [This frame is a (suspected) retransmission]
                [The RTO for this segment was: 239.926993000 seconds]
                [RTO based on delta from frame: 3]
    Data (1448 bytes)
        Data: 485454502F312E3120323030204F4B0D0A436F6E6E656374...

    0000  00 50 04 ce ee 01 00 15 f9 29 df 05 08 00 45 00   .P.......)....E.
    0010  05 dc a1 f3 40 00 31 06 cf 5b 80 79 0a 72 18 f3   ....@.1..[.y.r..
    0020  2e ef 08 20 d1 3b 3c 21 36 56 fc f1 fa f2 80 10   ... .;V
    0300  7b e1 88 8f 04 e1 19 ef 3d 56 66 78 37 de 41 e9   {.......=Vfx7.A.
    0310  d3 9d b7 2e ed 8b 0c 92 04 85 9d f5 e3 0c 82 9d   ................
    0320  ff 0a 33 1a 1b c8 07 3b 0b 38 91 2a b3 d8 19 13   ..3....;.8.*....
    0330  ca 17 3b ff f5 b3 2f 16 91 b7 f3 8f af be 07 20   ..;.../........ 
    0340  5f bf a3 0d 99 7e 52 b6 47 8b 24 63 ce 5f 1f 26   _....~R.G.$c._.&
    0350  2e eb 08 86 e4 03 7f 8d 8c bf 7d fb a8 75 b5 0e   ..........}..u..
    0360  7f 61 d5 01 28 4d 2c c6 bc 6f 9f da 0f 60 1e ab   .a..(M,..o...`..
    0370  19 df e4 5f 7e d3 bb ae df 5f 1e f1 be d3 44 7a   ..._~...._....Dz
    0380  45 07 8f 99 a2 3e 74 f2 65 a8 e0 dc 62 63 a6 8b   E....>t.e...bc..
    0390  f9 0d 8e ec 7b 69 b7 8d 8e ee 6f d6 bd 45 67 8f   ....{i....o..Eg.
    03a0  b3 81 66 ba 09 2c f7 7c c4 16 8f 39 a3 98 9e 3d   ..f..,.|...9...=
    03b0  a2 22 a6 ba 7b 0d 61 8f f9 a6 b2 bb 0d 8f 79 71   ."..{.a.......yq
    03c0  59 9d 09 0c be dc 63 b8 a6 bb 7b 19 cf 7d f2 be   Y.....c...{..}..
    03d0  eb b3 f6 9c 7d 85 89 bf 9a fb b6 4d 11 bf 4b ee   ....}......M..K.
    03e0  e6 ea ea cc 32 45 f8 45 6f ed 71 68 73 bd 89 66   ....2E.Eo.qhs..f
    03f0  f3 77 af 78 83 70 db 63 73 66 bb 7d 19 a3 3b 56   .w.x.p.csf.}..;V
    0400  4f 78 45 2f ef a5 25 8e 99 b2 8c 9a ee 31 4d 3e   OxE/..%......1M>
    0410  b7 41 4d dc 5b 06 ba bd bf d0 d3 bd b5 b3 bd 47   .AM.[..........G
    0420  be a7 91 11 7f 5e aa f1 20 a7 38 c1 3f b2 b7 6e   .....^.. .8.?..n
    0430  33 25 7a c5 1e 8f 18 a7 9e bc f1 51 8f 7b 04 ee   3%z........Q.{..
    0440  71 c1 32 bd 7f 2d cf a2 b9 de 95 d3 2c f8 85 53   q.2..-......,..S
    0450  8f ba bf a2 ce 67 d2 dc ab 58 ef cd 67 78 d1 d3   .....g...X..gx..
    0460  54 7c 15 4e dd 57 56 ba 15 6e dd 63 7c 7e b0 c0   T|.N.WV..n.c|~..
    0470  73 eb 85 d3 7c 57 ef fd e8 67 bb 4b 1e b1 93 d3   s...|W...g.K....
    0480  35 7a 45 6f 8f 58 bd 18 ba 3d a2 1a 66 ba e9 19   5zEo.X...=..f...
    0490  9b 3f a2 7e 54 1e 19 9f 3e bb 07 fe d4 5d ef 7e   .?.~T...>....].~
    04a0  23 af 65 6c e0 6b e9 fe a9 6f 61 6d e0 f8 9e dc   #.el.k...oam....
    04b0  38 80 46 7c ef 06 f8 2c 8b d9 95 db 46 88 8f 8d   8.F|...,....F...
    04c0  8f 0b 6c fc 3a 82 37 ff 1c 75 d2 3a e5 b9 3a e9   ..l.:.7..u.:..:.
    04d0  db 59 d2 00 83 51 94 d8 03 22 56 ca eb 53 c6 d3   .Y...Q..."V..S..
    04e0  c7 77 72 66 64 6b 7b 56 66 62 7a 72 56 64 63 7f   .wrfdk{VfbzrVdc.
    04f0  74 30 19 7e 58 4e fa 67 a6 3e 2d 13 84 0d 84 14   t0.~XN.g.>-.....
    0500  89 0b 85 02 3b 5f 89 84 8c 1c 88 23 3e 1b bb 8e   ....;_.....#>...
    0510  f6 09 74 b1 34 b2 72 f0 d2 85 fd a3 d4 14 65 c0   ..t.4.r.......e.
    0520  c9 7e b7 ff 2b 09 07 13 32 62 6a 7d 7d e3 e3 e0   .~..+...2bj}}...
    0530  28 a5 a3 0e 50 9e c8 70 33 f8 e9 ae 59 e4 9c af   (...P..p3...Y...
    0540  b7 3b af 35 c0 c4 cc 9c c7 04 00 60 7a 01 64 ab   .;.5.......`z.d.
  • No.     Time        Source                Destination           Protocol Info
          6 8986.578320 128.121.10.114        24.243.46.239         TCP      [TCP Retransmission] autodesk-nlm > 53563 [ACK] Seq=1 Ack=1 Win=6432 Len=1448 TSV=2519558501 TSER=3478199

    Frame 6 (1514 bytes on wire, 1514 bytes captured)
        Arrival Time: Jan  9, 2009 18:31:59.787471000
        [Time delta from previous captured frame: 119.975054000 seconds]
        [Time delta from previous displayed frame: 119.975054000 seconds]
        [Time since reference or first frame: 8986.578320000 seconds]
        Frame Number: 6
        Frame Length: 1514 bytes
        Capture Length: 1514 bytes
        [Frame is marked: False]
        [Protocols in frame: eth:ip:tcp[:D]ata]
        [Coloring Rule Name: Bad TCP]
        [Coloring Rule String: tcp.analysis.flags]
    Ethernet II, Src: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05), Dst: 3com_ce:ee:01 (00:50:04:ce:ee:01)
        Destination: 3com_ce:ee:01 (00:50:04:ce:ee:01)
            Address: 3com_ce:ee:01 (00:50:04:ce:ee:01)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Source: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05)
            Address: Cisco_29[:D]f:05 (00:15:f9:29[:D]f:05)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Type: IP (0x0800)
    Internet Protocol, Src: 128.121.10.114 (128.121.10.114), Dst: 24.243.46.239 (24.243.46.239)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 1500
        Identification: 0xa1f5 (41461)
        Flags: 0x04 (Don't Fragment)
            0... = Reserved bit: Not set
            .1.. = Don't fragment: Set
            ..0. = More fragments: Not set
        Fragment offset: 0
        Time to live: 49
        Protocol: TCP (0x06)
        Header checksum: 0xcf59 [correct]
            [Good: True]
            [Bad : False]
        Source: 128.121.10.114 (128.121.10.114)
        Destination: 24.243.46.239 (24.243.46.239)
    Transmission Control Protocol, Src Port: autodesk-nlm (2080), Dst Port: 53563 (53563), Seq: 1, Ack: 1, Len: 1448
        Source port: autodesk-nlm (2080)
        Destination port: 53563 (53563)
        Sequence number: 1    (relative sequence number)
        [Next sequence number: 1449    (relative sequence number)]
        Acknowledgement number: 1    (relative ack number)
        Header length: 32 bytes
        Flags: 0x10 (ACK)
            0... .... = Congestion Window Reduced (CWR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...1 .... = Acknowledgment: Set
            .... 0... = Push: Not set
            .... .0.. = Reset: Not set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 6432
        Checksum: 0x0995 [correct]
            [Good Checksum: True]
            [Bad Checksum: False]
        Options: (12 bytes)
            NOP
            NOP
            Timestamps: TSval 2519558501, TSecr 3478199
        [SEQ/ACK analysis]
            [TCP Analysis Flags]
                [This frame is a (suspected) retransmission]
                [The RTO for this segment was: 359.902047000 seconds]
                [RTO based on delta from frame: 3]
    Data (1448 bytes)
        Data: 485454502F312E3120323030204F4B0D0A436F6E6E656374...

    0000  00 50 04 ce ee 01 00 15 f9 29 df 05 08 00 45 00   .P.......)....E.
    0010  05 dc a1 f5 40 00 31 06 cf 59 80 79 0a 72 18 f3   ....@.1..Y.y.r..
    0020  2e ef 08 20 d1 3b 3c 21 36 56 fc f1 fa f2 80 10   ... .;V
    0300  7b e1 88 8f 04 e1 19 ef 3d 56 66 78 37 de 41 e9   {.......=Vfx7.A.
    0310  d3 9d b7 2e ed 8b 0c 92 04 85 9d f5 e3 0c 82 9d   ................
    0320  ff 0a 33 1a 1b c8 07 3b 0b 38 91 2a b3 d8 19 13   ..3....;.8.*....
    0330  ca 17 3b ff f5 b3 2f 16 91 b7 f3 8f af be 07 20   ..;.../........ 
    0340  5f bf a3 0d 99 7e 52 b6 47 8b 24 63 ce 5f 1f 26   _....~R.G.$c._.&
    0350  2e eb 08 86 e4 03 7f 8d 8c bf 7d fb a8 75 b5 0e   ..........}..u..
    0360  7f 61 d5 01 28 4d 2c c6 bc 6f 9f da 0f 60 1e ab   .a..(M,..o...`..
    0370  19 df e4 5f 7e d3 bb ae df 5f 1e f1 be d3 44 7a   ..._~...._....Dz
    0380  45 07 8f 99 a2 3e 74 f2 65 a8 e0 dc 62 63 a6 8b   E....>t.e...bc..
    0390  f9 0d 8e ec 7b 69 b7 8d 8e ee 6f d6 bd 45 67 8f   ....{i....o..Eg.
    03a0  b3 81 66 ba 09 2c f7 7c c4 16 8f 39 a3 98 9e 3d   ..f..,.|...9...=
    03b0  a2 22 a6 ba 7b 0d 61 8f f9 a6 b2 bb 0d 8f 79 71   ."..{.a.......yq
    03c0  59 9d 09 0c be dc 63 b8 a6 bb 7b 19 cf 7d f2 be   Y.....c...{..}..
    03d0  eb b3 f6 9c 7d 85 89 bf 9a fb b6 4d 11 bf 4b ee   ....}......M..K.
    03e0  e6 ea ea cc 32 45 f8 45 6f ed 71 68 73 bd 89 66   ....2E.Eo.qhs..f
    03f0  f3 77 af 78 83 70 db 63 73 66 bb 7d 19 a3 3b 56   .w.x.p.csf.}..;V
    0400  4f 78 45 2f ef a5 25 8e 99 b2 8c 9a ee 31 4d 3e   OxE/..%......1M>
    0410  b7 41 4d dc 5b 06 ba bd bf d0 d3 bd b5 b3 bd 47   .AM.[..........G
    0420  be a7 91 11 7f 5e aa f1 20 a7 38 c1 3f b2 b7 6e   .....^.. .8.?..n
    0430  33 25 7a c5 1e 8f 18 a7 9e bc f1 51 8f 7b 04 ee   3%z........Q.{..
    0440  71 c1 32 bd 7f 2d cf a2 b9 de 95 d3 2c f8 85 53   q.2..-......,..S
    0450  8f ba bf a2 ce 67 d2 dc ab 58 ef cd 67 78 d1 d3   .....g...X..gx..
    0460  54 7c 15 4e dd 57 56 ba 15 6e dd 63 7c 7e b0 c0   T|.N.WV..n.c|~..
    0470  73 eb 85 d3 7c 57 ef fd e8 67 bb 4b 1e b1 93 d3   s...|W...g.K....
    0480  35 7a 45 6f 8f 58 bd 18 ba 3d a2 1a 66 ba e9 19   5zEo.X...=..f...
    0490  9b 3f a2 7e 54 1e 19 9f 3e bb 07 fe d4 5d ef 7e   .?.~T...>....].~
    04a0  23 af 65 6c e0 6b e9 fe a9 6f 61 6d e0 f8 9e dc   #.el.k...oam....
    04b0  38 80 46 7c ef 06 f8 2c 8b d9 95 db 46 88 8f 8d   8.F|...,....F...
    04c0  8f 0b 6c fc 3a 82 37 ff 1c 75 d2 3a e5 b9 3a e9   ..l.:.7..u.:..:.
    04d0  db 59 d2 00 83 51 94 d8 03 22 56 ca eb 53 c6 d3   .Y...Q..."V..S..
    04e0  c7 77 72 66 64 6b 7b 56 66 62 7a 72 56 64 63 7f   .wrfdk{VfbzrVdc.
    04f0  74 30 19 7e 58 4e fa 67 a6 3e 2d 13 84 0d 84 14   t0.~XN.g.>-.....
    0500  89 0b 85 02 3b 5f 89 84 8c 1c 88 23 3e 1b bb 8e   ....;_.....#>...
    0510  f6 09 74 b1 34 b2 72 f0 d2 85 fd a3 d4 14 65 c0   ..t.4.r.......e.
    0520  c9 7e b7 ff 2b 09 07 13 32 62 6a 7d 7d e3 e3 e0   .~..+...2bj}}...
    0530  28 a5 a3 0e 50 9e c8 70 33 f8 e9 ae 59 e4 9c af   (...P..p3...Y...
    0540  b7 3b af 35 c0 c4 cc 9c c7 04 00 60 7a 01 64 ab   .;.5.......`z.d.
  • You can't spoof TCP sessions (although SYN's and RST's can be spoofed).

    BTW, the subject was "Unknown OUTBOUND traffic"... what makes you think it's outbound?

    Barry


    Previous lack of response from the forum and understanding from myself.
    The traffic appeared to be from up2date server ranges.
    But when I captured the packets there was no outbound to the same IP. The packets were as I posted.

    Can you explain what they were trying to accomplish from the packets that I posted?
    I had to truncate the last few line of the Hex on each packet.
  • Hmm... something's definitely making a full connection.

    Where are you sniffing? on the firewall, or in the LAN, or outside the firewall?

    Are either of these IPs in your LAN/DMZ?
    128.121.10.114 
    24.243.46.239 

    If not, AND if you're sniffing your internet connection, then your ISP may have your router (or modem) misconfigured, letting you see other customer's connections.

    Barry
  • Hm, maybe I can sched some light on this, at least part of it.

    In our up2date infrastructure, the actual up2date servers are shielded by ASGs. The up2date server which is located in Sterling, USA (v7up2date5.astaro.com, 128.121.10.115) is behind an ASG (128.121.10.114) which has the official IP address of the up2date server as an alias and uses DNAT to forward the requests to the up2date server. Because of the server configuration, the server is listening on port 2080 (instead of 80) for up2date download requests, so the ASG uses DNAT for 128.121.10.115:80 -> internal.ip.of.the.up2date.server:2080 .

    What you are seeing there is the end of an up2date download, originating from our up2date server in Sterling. The strange thing is that the connection originating from 2080 should never go outside of the internal network, as it should be translated back to the 'official' source ip (alias on the ASG) as well as the official source port (80) of the download. For those packets that you are seeing, the ASG seems to route them instead of DNATing them back.

    So, on the positive side - those packets are no attacks, and no probing attempts. My personal assumption is that the linux network stack is having hickups there, probably in high load situations.

    Cheers,
     Andreas
  • Thank you.

    I was hoping that it was something like that and not rouge Astaro folks snooping. If the NSA can abuse their power and post your and my most intimate momnets on a big screen for their buddies to see anyone can abuse their access. I am glad that is not the case.

    Here is my orgininal question:

    http://www.astaro.org/astaro-gateway-products/management-networking-logging-reporting/21301-unknown-outbound-traffic.html

    Lets try this again...

    I am curious about the traffic from IP addresses:
    128.242.114.242 (rdns mail2.after.college.com) at NTT America.
    218.213.238.228 (no rdns) at HKNET-Hong Kong.
    213.198.65.27 (rdns euu0300091-pip.eu.verio.net) NTT/Verio Europe.
    69.10.147.66 (rdns unknown.rackforce.com) at RackForce Hosting.

    Specifically regarding src port 2080.

    src port is always 2080
    dst port varies (30000-59999)
    all traffic is tcp
    The only proxys involved are on/in the ASG box. If any other proxies outside my modem exist I would like to know.

    Since from what I have observed, up2date appears to use only ports 443 and 80. Because of this belief, the traffic described herein appears odd to me. 

    Does up2date also require port 2080 to function correctly or close a connection? The packet data captured in front of the ASG indicates that the connection is trying to close and is retransmitting. These retransmissions are what the ASG's packet capture feature is logging. I do not know what the standard is for making sure a port is closed, but since the traffic is tcp and not udp I do not believe that 24 packets are required to close a connection. Which is what the ASG logged this morning from 09:38 to 10:00 GMT from IP 128.242.114.242 to two different dst ports (48775 and 37739). Am I wrong about anything I have stated?

    Note: I have port 2080 blocked in the packet filter rules (along with many other ports). 

    This traffic causes me some anxiety since I do not know the purpose of the traffic's original cause.

    Will someone please explain this traffic?

    Note: All my log data is sent to both Mynetwatchman and Dshield.

    out.


    Unanswered Questions:

    1) Am I correct about up2date only using port 443 and 80.

    2) Shoud I include port 2080 in my packetfilter rule for the up2date servers? Or do I leave the port blocked (two separate rules)? You did say that port 2080 should never have been seen at all? Yes, I think that is what you said (internal network only). Did you say that? So, I gues I should leave it blocked, right?

    Previously, I was asked if I used a proxy. The only proxy of which I know is the CMTS of my ISP. (and now Astaro's) I have had my suspicions since when my LAN was on a 10/8 net and so is their CMTS I had some major problems with unauthorized access. Just a hop across a router I thought...But that is another story. I now own the modem as well.

    3) Could a proxy cause a delay? Or has the actual problem been identified as problems with the Astaro proxy's SNAT... (not DNAT???)... since I received the "ACK"?

    If you would like, I can go all the way back to Jan 2008 and tell you all of the servers that have sent out the proxy port 2080 and the dates and times they did it. This is not an isolated incident it happens daily. I should have pursued this back on March 25th of 2008 when I first posted. I had my hands full then, sorry. My initial inclination says that having the proxy port on the internet is a bad thing. Is it? Does the ASG do it too?

    Thanks again for your time.

    Jim

  • 1) Am I correct about up2date only using port 443 and 80. 

    Yes. 443 is used for authentication, 80 is used for download.

    2) Shoud I include port 2080 in my packetfilter rule for the up2date servers? Or do I leave the port blocked (two separate rules)? You did say that port 2080 should never have been seen at all? Yes, I think that is what you said (internal network only). Did you say that? So, I gues I should leave it blocked, right?

    You don't need to unblock port 2080. The fact that you are seeing packets coming from that port is a malfunction on our side. TCP check/retransmission mechanisms will take care of this, so you don't need to do anything.


    3) Could a proxy cause a delay? Or has the actual problem been identified as problems with the Astaro proxy's SNAT... (not DNAT???)... since I received the "ACK"?

    First of all, we don't use the proxy functionality on the ASGs that shield the up2date servers. The ASGs are using DNAT to rewrite the destination of the initial connection. The source address in the reply packets for this connection is automatically rewritten by the netfilter. And yes, having a proxy port open to the internet is not a good idea. The ASG will not do this unless you configure it explicitly to do so.

    Cheers,
     andreas
  • Hmm... something's definitely making a full connection.

    Where are you sniffing? on the firewall, or in the LAN, or outside the firewall?

    Are either of these IPs in your LAN/DMZ?
    128.121.10.114 
    24.243.46.239 

    If not, AND if you're sniffing your internet connection, then your ISP may have your router (or modem) misconfigured, letting you see other customer's connections.

    Barry


    I am cocerned about a CMTS misconfiguration or some sort of bleed-over hardware failure, and have been for some time. Except, it would be other folks seeing my connections. My ISP is less than helpful. As of yet, they have not written a readable script for someone to read to me from tech support. It appears that as long as I can connect and surf, then everything is A-OK. Tier three support is next to impossible to get transferred to now. A great new policy...

    I own my modem. From what I can see, config appears ok. However, my understanding may be lacking in what "normal" looks like.

    The original problem has been addressed.

    I appreciate everyone's time and effort.

    Jim
  • Hi Jim,
    I think it would have been a little less confusing to me if you had identified which IP was yours.
    Glad it's straightened out now.

    Barry
  • Sorry.

    I thought everyone had a laminated list of Astaro server IP addresses hanging on a lanyard around their neck for reference.


    But Seriously, thanks for your help.


    Jim