odd packets being blocked by firewall

Discussion in 'Home Networking' started by Mike Scott, Mar 18, 2013.

  1. Mike Scott

    Mike Scott Guest

    I'm puzzled. I've got a pf firewall running on a freebsd server. It logs
    (while blocking) a lot of inbound packets from the net to a specific
    high port number 31534, and a weirdly consistent ack tcp field. The
    source port often (always??) seems to be a well-known port number.

    For example, from the top of the pf log with tcpdump and and grepping
    for 31534:

    2013-03-18 15:38:18.426396 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:26:03.859559 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:25:54.482970 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:25:54.277156 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:25:53.910192 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:25:53.875597 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 15:03:04.016158 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:52:03.479254 rule 6/0(match): block in on re1:
    173.1.25.25.22 > 192.168.1.1.31534: Flags [S.], seq 1974296249, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 14:51:04.984589 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:50:57.743123 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:50:57.711532 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:50:57.216857 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:50:57.157120 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.31534: Flags [S.], seq 522742529, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-18 14:37:14.686595 rule 6/0(match): block in on re1:
    173.1.25.20.22 > 192.168.1.1.31534: Flags [S.], seq 1741785167, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 14:25:46.114635 rule 6/0(match): block in on re1:
    173.1.25.25.22 > 192.168.1.1.31534: Flags [S.], seq 615542810, ack
    522112775, win 16384, options [mss 1460], length 0

    (192.168.1.1 re1 is the WAN interface of my gateway box, which connects
    to a modem/router. The latter is set to route everything straight to the
    gateway. Each does its own natting.)

    AFAICT nothing ever goes out to port 31534.

    I've no idea what the significance of the particular port might be; that
    different addresses are using the same ack number I find suspicious. And
    all the packets I've seen have had the S flag set.

    Has anyone noticed anything similar or suggest what's going on please?

    TIA.
     
    Mike Scott, Mar 18, 2013
    #1
    1. Advertisements

  2. Mike Scott

    Dave Saville Guest

    No idea on your problem, but why are you double NATing everything?
     
    Dave Saville, Mar 18, 2013
    #2
    1. Advertisements

  3. Mike Scott

    Mike Scott Guest

    It doesn't hurt; and the replacement modem/router I put in a few weeks
    ago is overkill for the job, and provides its own nat, while the
    (freebsd) gateway box has always been where my firewall did the natting.
    I took the easy route and left well alone :)
     
    Mike Scott, Mar 18, 2013
    #3
  4. Servers do send acks back to client ephemeral ports in reply to the fin/acks
    at the ends of TCP connections.
     
    Anthony R. Gold, Mar 18, 2013
    #4
  5. Mike Scott

    Mike Scott Guest

    Except these come from various machines to which, AFAICT, there has
    never been a connection (I log all SYN requests at the firewall).

    And it continues - this morning, I see the most recent entries are:

    22013-03-19 08:20:14.642794 rule 6/0(match): block in on re1:
    195.211.223.51.80 > 192.168.1.1.31534: Flags [S.], seq 2984288239, ack
    522112775, win 65535, options [mss 1460,sackOK,eol], length 0
    2013-03-19 08:20:09.102663 rule 6/0(match): block in on re1:
    195.211.223.51.80 > 192.168.1.1.31534: Flags [S.], seq 684539749, ack
    522112775, win 65535, options [mss 1460,sackOK,eol], length 0
    2013-03-19 08:20:08.975077 rule 6/0(match): block in on re1:
    195.211.223.51.80 > 192.168.1.1.31534: Flags [S.], seq 684539749, ack
    522112775, win 65535, options [mss 1460,sackOK,eol], length 0
    2013-03-19 08:20:08.962045 rule 6/0(match): block in on re1:
    195.211.223.51.80 > 192.168.1.1.31534: Flags [S.], seq 684539749, ack
    522112775, win 65535, options [mss 1460,sackOK,eol], length 0
    2013-03-19 08:12:56.795871 rule 6/0(match): block in on re1:
    46.108.60.22.80 > 192.168.1.1.31534: Flags [S.], seq 20031978, ack
    522112775, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    2013-03-19 07:08:26.728473 rule 6/0(match): block in on re1:
    198.1.89.103.22 > 192.168.1.1.31534: Flags [S.], seq 1372535650, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-19 06:45:22.392355 rule 6/0(match): block in on re1:
    174.120.127.90.80 > 192.168.1.1.31534: Flags [S.], seq 1684467683, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 22:49:53.822882 rule 6/0(match): block in on re1:
    75.126.152.83.8405 > 192.168.1.1.31534: Flags [S.], seq 3759956609, ack
    522112775, win 65535, options [mss 1460], length 0


    Note the several different IPs, yet the fixed 'ack 522112775' from all.
     
    Mike Scott, Mar 19, 2013
    #5
  6. If you’d attempted to connect to 192.31.185.155.80 then this looks
    exactly like the first packet you’d see in response. 31534 would have
    been chosen at your end, as would 522112775.
    ....and so does this. If your end was ignoring the responses then you’d
    expect to see some level of retry.
    Much the same conditions would explain this, with the exception of the
    matching port and sequence numbers. If your inner NAT device doesn’t
    choose these randomly that could explain that.

    The double NAT means that you can’t actually be sure what the packets
    looked like before the outer NAT got its hands on them, unfortunately.

    31534 is the local port number. The question would be whether anything
    goes out *from* that port.

    173.1.25.20 belongs to someone called gogrid.com; is that familiar (as
    something you might SSH to)? If it is then I’d suggest you’re actually
    seeing fallout from some local misconfiguration.

    If not then I can think of a couple of possibilities:

    (1) Some kind of (weird and inefficient!) scanning attempt.

    (2) Someone else thinks they have your globally routable IP address, so
    what you are seeing is the responses to their attempts to initiate
    outbound connections. They will currently be wondering why their
    Internet connection doesn’t work.

    In this case the consistent port and sequence numbers may be an artefact
    of their kit or may be a result of the outer NAT. You’d need to see the
    actual inbound packets rather than the NAT-mangled ones to distinguish
    these possibilities.
    I would expect [F.] rather than [S.] if that was what was going on.
     
    Richard Kettlewell, Mar 19, 2013
    #6
  7. Mike Scott

    Mike Scott Guest

    That particular address is Black Lotus Communications. Slight red face -
    I should have searched for the IP rather than port, and it seems mint
    (or ubuntu) does chat to this IP off its own bat. But nevertheless, the
    firewall log shows no sign of an outbound connect from port 31534: the
    start of the log shows (nb oldest last))

    %sudo /usr/plumtree/root-tools/pfdumplog | grep 192.31.185.155 | tail -6
    2013-03-14 17:28:40.414361 rule 6/0(match): block in on re1:
    192.31.185.155.8080 > 192.168.1.1.31534: Flags [S.], seq 522726122, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-14 17:28:40.295442 rule 6/0(match): block in on re1:
    192.31.185.155.8080 > 192.168.1.1.31534: Flags [S.], seq 522726122, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-13 20:35:01.778146 rule 6/0(match): block in on re1:
    192.31.185.155.30800 > 192.168.1.1.31534: Flags [S.], seq 522742409, ack
    522112775, win 65535, options [mss 1460], length 0
    2013-03-10 08:28:03.708633 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.54803: Flags [S.], seq 984928981, ack
    984021888, win 65535, options [mss 1460], length 0
    2013-03-09 20:55:44.560494 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.30388: Flags [S.], seq 125495353, ack
    124629572, win 65535, options [mss 1460], length 0
    2013-03-09 16:10:50.405790 rule 6/0(match): block in on re1:
    192.31.185.155.80 > 192.168.1.1.30388: Flags [S.], seq 125495353, ack
    124629572, win 65535, options [mss 1460], length 0
    %


    OTOH, the only entry for 173.1.25.20.22 in the whole log(*) is

    %sudo /usr/plumtree/root-tools/pfdumplog | grep 173.1.25.20
    2013-03-18 14:37:14.686595 rule 6/0(match): block in on re1:
    173.1.25.20.22 > 192.168.1.1.31534: Flags [S.], seq 1741785167, ack
    522112775, win 16384, options [mss 1460], length 0

    and I can't imagine why anything here would (or could) want to ssh out
    to that IP in the first place.

    (*) My firewall log has all SYN requests and blocked packets logged, and
    extends back to late Jan, btw)

    (Paranoia mode - could the modem/router firmware call out to the net, I
    wonder? I could never see the packets if it did, as they'd just be on
    the phone wire, but it /might/ result in things like this popping out
    the LAN side occasionally. No... couldn't be. Could it?)

    ....
    Freebsd/pf - should behave fairly well, I think. I've not noticed any
    predisposition to non-randomness.
    Yeh, sorry, meant to say 'from'.
    I've disabled the netgear router's NAT now. Will see what difference if
    any that makes. Maybe I should have done this when I set it up - but
    it's one of those things that normally makes no odds, so I just left it.

    Thanks for the comments. I'll see what happens the next day or three,
    and hope for some clarity.
     
    Mike Scott, Mar 19, 2013
    #7
  8. Mike Scott

    Mike Scott Guest

    On 19/03/13 11:33, Mike Scott wrote:
    ....
    Ooops. Well, I thought I had when I wrote that - if I turn off the
    router's nat, I get nothing back, not even to a ping to an IP address.
    Needs checking out.
     
    Mike Scott, Mar 19, 2013
    #8
  9. Mike Scott

    Mike Scott Guest

    I'm not sure what's happening.... if I turn off the netgear's NAT, the
    router is supposed to do "normal routing". But although the routing
    tables look fine, I get nothing back from the net. So I'm a bit stuck
    there.

    Meanwhile, although as a side effect my IP address has changed, I'm
    still getting the strange tcp stuff coming in:

    %sudo /usr/plumtree/root-tools/pfdumplog |grep 185.7.248.1
    2013-03-18 20:06:26.225976 rule 6/0(match): block in on re1:
    185.7.248.1.22 > 192.168.1.1.31534: Flags [S.], seq 1147418455, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 19:57:12.181347 rule 6/0(match): block in on re1:
    185.7.248.1.22 > 192.168.1.1.31534: Flags [S.], seq 31094880, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 19:51:07.056061 rule 6/0(match): block in on re1:
    185.7.248.1.22 > 192.168.1.1.31534: Flags [S.], seq 679210800, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 19:50:38.680854 rule 6/0(match): block in on re1:
    185.7.248.1.80 > 192.168.1.1.31534: Flags [S.], seq 24671409, ack
    522112775, win 16384, options [mss 1460], length 0
    2013-03-18 19:33:56.149366 rule 6/0(match): block in on re1:
    185.7.248.1.80 > 192.168.1.1.31534: Flags [S.], seq 343371352, ack
    522112775, win 16384, options [mss 1460], length 0

    by way of example. Same local port, same ack number. The log goes back
    to Jan; there's no trace of corresponding SYN packets.
     
    Mike Scott, Mar 23, 2013
    #9
  10. Mike Scott

    grinch Guest

    Given that your internal IP address is part of the RFC 1918 space I am
    not surprised try Google rfc1918 for why.

    Does firewall rule 6 block empty packets by any chance ? I notice that
    all the packets have length 0 ,which I assume means they are empty??
     
    grinch, Mar 23, 2013
    #10
  11. Mike Scott

    Mike Scott Guest

    On reflection, neither am I. Can't possibly work. (Kicks self....)
    rule 6 is the default "block anything that doesn't match something more
    useful" rule. I take your point about the packets being logged as zero
    length - presumably that's just the tcp data length though, as the
    header stuff is obviously present. Doesn't explain why they're there -
    these were the only packets relating to that host in nearly two months
    of firewall logs (I log all syn packets, in and outbound: Don't ask :) )
     
    Mike Scott, Mar 25, 2013
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.