A Broadband and ADSL forum. BroadbanterBanter

Welcome to BroadbanterBanter.

You are currently viewing as a guest which gives you limited access to view most discussions and other FREE features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today.

Go Back   Home » BroadbanterBanter forum » Newsgroup Discussions » uk.comp.home-networking (UK home networking)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

uk.comp.home-networking (UK home networking) (uk.comp.home-networking) Discussion of all aspects of computer networking in the home, regardless of the platforms, software, topologies and protocols used. Examples of topics include recommendations for hardware or suppliers (e.g. NICs and cabling), protocols, servers, and specific network software. Advertising is not allowed.

odd packets being blocked by firewall



 
 
Thread Tools Display Modes
  #1  
Old March 18th 13, 04:56 PM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #2  
Old March 18th 13, 05:29 PM posted to uk.comp.home-networking
Dave Saville
external usenet poster
 
Posts: 138
Default odd packets being blocked by firewall

On Mon, 18 Mar 2013 15:56:37 UTC, Mike Scott
wrote:

(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.)


No idea on your problem, but why are you double NATing everything?

--
Regards
Dave Saville
  #3  
Old March 18th 13, 07:42 PM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

On 18/03/13 16:29, Dave Saville wrote:
On Mon, 18 Mar 2013 15:56:37 UTC, Mike Scott
wrote:

(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.)


No idea on your problem, but why are you double NATing everything?


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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #4  
Old March 18th 13, 10:16 PM posted to uk.comp.home-networking
Anthony R. Gold
external usenet poster
 
Posts: 362
Default odd packets being blocked by firewall

On Mon, 18 Mar 2013 15:56:37 +0000, Mike Scott
wrote:

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?


Servers do send acks back to client ephemeral ports in reply to the fin/acks
at the ends of TCP connections.
  #5  
Old March 19th 13, 09:24 AM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

On 18/03/13 21:16, Anthony R. Gold wrote:
On Mon, 18 Mar 2013 15:56:37 +0000, Mike Scott
wrote:

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

....

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?


Servers do send acks back to client ephemeral ports in reply to the fin/acks
at the ends of TCP connections.


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 a

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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #6  
Old March 19th 13, 11:51 AM posted to uk.comp.home-networking
Richard Kettlewell
external usenet poster
 
Posts: 1
Default odd packets being blocked by firewall

"Anthony R. Gold" writes:
Mike Scott wrote:


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


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.

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


....and so does this. If your end was ignoring the responses then you'd
expect to see some level of retry.

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: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


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.

(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.)


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.

AFAICT nothing ever goes out to port 31534.


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

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?


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.

Servers do send acks back to client ephemeral ports in reply to the
fin/acks at the ends of TCP connections.


I would expect [F.] rather than [S.] if that was what was going on.

--
http://www.greenend.org.uk/rjk/
  #7  
Old March 19th 13, 12:33 PM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

On 19/03/13 10:51, Richard Kettlewell wrote:
"Anthony R. Gold" writes:
Mike Scott wrote:


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


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.


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?)

....
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.


Freebsd/pf - should behave fairly well, I think. I've not noticed any
predisposition to non-randomness.


(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.)


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.

AFAICT nothing ever goes out to port 31534.


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


Yeh, sorry, meant to say 'from'.


....

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'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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #8  
Old March 19th 13, 12:42 PM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

On 19/03/13 11:33, Mike Scott wrote:
....
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.


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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #9  
Old March 23rd 13, 08:16 AM posted to uk.comp.home-networking
Mike Scott
external usenet poster
 
Posts: 14
Default odd packets being blocked by firewall

On 19/03/2013 11:42, Mike Scott wrote:
On 19/03/13 11:33, Mike Scott wrote:
...
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.


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.



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 (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England
  #10  
Old March 23rd 13, 03:45 PM posted to uk.comp.home-networking
grinch
external usenet poster
 
Posts: 70
Default odd packets being blocked by firewall

On 23/03/13 07:16, Mike Scott wrote:
On 19/03/2013 11:42, Mike Scott wrote:
On 19/03/13 11:33, Mike Scott wrote:
...
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.


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.



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.


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


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.



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??

 




Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Losing Packets! Chris Curtis uk.telecom.broadband (UK broadband) 13 November 20th 07 12:42 PM
Netgear WAP with large packets? Matt Birchall uk.comp.home-networking (UK home networking) 0 December 5th 06 08:17 PM
dropping packets to distrupt voip? Ken Williams uk.telecom.voip (UK VOIP) 8 December 3rd 06 03:17 AM
Packets not being ACKd Tommy uk.telecom.broadband (UK broadband) 0 November 19th 06 11:58 AM
Odd - Turnpike News & DrayTek 2600 firewall bof uk.telecom.broadband (UK broadband) 4 January 9th 04 01:46 AM


All times are GMT +1. The time now is 07:58 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.Content Relevant URLs by vBSEO 2.4.0
Copyright 2004-2019 BroadbanterBanter.
The comments are property of their posters.