Hi Jean-Laurent,
Op 25-6-2016 om 10:37 schreef Jean-Laurent Ivars:
This is logs generated by tcpdump from the same client machine when I try to
access the firewall thru working internet access provider :
port 2223
16:55:04.501509 IP 46.105.230.225.39304 > 192.168.101.254.2223: Flags [P.], seq
29:701, ack 22, win 32844, length 672
16:55:04.501652 IP 192.168.101.254.2223 > 46.105.230.225.39304: Flags [P.], seq
22:910, ack 701, win 508, length 888
port 10000
16:58:51.821691 IP 192.168.101.254.10000 > 46.105.230.225.5829: Flags [P.], seq
209411:210119, ack 2393, win 513, length 708
16:58:52.058014 IP 46.105.230.225.5829 > 192.168.101.254.10000: Flags [.], ack
210119, win 32673, length 0
Both these captures are in the 'middle' of a already working connection,
but does show it 'works' at that time.. To compare it to the capture
below better start capturing before initiation the connection :) .
And there the same command output when I try to access from one that is not
working :
Port 2223
16:53:13.240166 IP 46.105.230.225.19480 > 192.168.101.254.2223: Flags [S], seq
3864438539, win 8192, options [mss 1460,nop,nop,sackOK], length 0
16:53:13.240306 IP 192.168.101.254.2223 > 46.105.230.225.19480: Flags [S.], seq
2492220538, ack 3864438540, win 65228, options [mss 1460,nop,wscale 7,sackOK,eol],
length 0
Port 10000
16:56:39.864021 IP 46.105.230.225.41932 > 192.168.101.254.10000: Flags [S], seq
2837326484, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
16:56:39.864169 IP 192.168.101.254.10000 > 46.105.230.225.41932: Flags [S.],
seq 1993261464, ack 2837326485, win 65228, options [mss 1460,nop,wscale
7,sackOK,eol], length 0
These SYN [S] and SYN-ACK [S.] packets are the normal start of a tcp
connection. Sofar nothing strange during connection initiation, there
should follow a 3rd ACK [.] packet after which there would follow some
useful data exchange like in the first working captures.. But i guess
you keep seeing these same two [S] and [S.] packets repeating.?
You have performed these captures on the LAN interface, could you repeat
them on the WAN interface to confirm that the [S.] is properly send back
on that same interface the client send the request on? Also if its
possible to capture on the client device it would be interesting to see
if the [S.] arrives there properly.
I use pcengine APU system, the model is AMD G-T40E Processor with 3 NIC ( I
believe It could be something related to a NIC setting somewhere but really
don’t know)
Is someone encounter the same issue than me ? maybe it’s just a setting in the
NIC driver ?
I don't expect it to be hardware/driver related at this moment..
Do you have any packages installed? Snort or Suricata can sometimes
unexpectedly block traffic you do want.. Or other configurations like
limiters/shapers or openvpn/ipsec networks can possibly interfere..
Regards,
PiBa-NL
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
