TCP Retransmission нет доступа к серверу

HelpUser

@Konstanti Я это вижу что идет сброс, и повтор от клиента, но мне почему то кажется что это pfsense делает сброс, но ПОЧЕМУ? Да возможно я не прав (возможно не сильно умен) и сброс идет от клиента, тогда тот же вопрос. Чем этому серверу не нравится pfsense?

Konstanti

@HelpUser
Сбрасывает именно сервер , больше никто
Причина может быть , по-моему, в том что

Или файрвол на сервере
Контрольные суммы tcp пакета
Запустите tcpdump на сервере с опцией -v ( нет ли ошибок) ?

Konstanti

@HelpUser Если будут ошибки контрольных сумм, то попробуйте в настройках PFSense System/Advanced/Networking
Сделать так

HelpUser

@Konstanti так делал не помогло, судя по дампу вроде бы все в порядке
1.txt

Konstanti

@HelpUser А если сделать исходящий NAT на lan интерфейсе PFSense для tcp-пакетов на порту 9090 ? Тогда сервер будет получать пакеты с ip-адресом lan интерфейса PF.

HelpUser

@Konstanti не совсем понял, привожу пример что сделал.

Konstanti

@HelpUser

HelpUser

@Konstanti
В правило попадает так

В правило попадает так
WAN tcp ВнешнийИПКлиента:23148 -> 10.10.10.19:9090 (ВнешнийИПСервера:9090) TIME_WAIT:TIME_WAIT 1 / 1 52 B / 40 B
WAN tcp ВнешнийИПКлиента:23150 -> 10.10.10.19:9090 (ВнешнийИПСервера:9090) TIME_WAIT:TIME_WAIT 1 / 1 52 B / 40 B
WAN tcp 93.158.156.96:50825 -> 10.10.10.19:9090 (ВнешнийИПСервера:9090) TIME_WAIT:TIME_WAIT 1 / 1 60 B / 40 B
WAN tcp ВнешнийИПКлиента:23147 -> 10.10.10.19:9090 (ВнешнийИПСервера:9090) TIME_WAIT:TIME_WAIT 1 / 1 52 B / 40 B

да судя по дампу с сервера
19:22:35.391537 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
имясервера.9090 > 10.10.10.50.63540: Flags [R.], cksum 0xd4f7 (correct), seq 0, ack 778528866, win 0, length 0

теперь локальный pfsensa появляется

HelpUser

This post is deleted!

Konstanti

@HelpUser said in TCP Retransmission нет доступа к серверу:

93.158.156.96

Если все сделано верно , то на сервере должно быть так
10.10.10.X:11111 -> 10.10.10.19:9090
Мне любопытно , ответит ли сервер сервер
Чтобы было Вам понятно , какой порядок настройки проброса портов с исходящим НАТ
покажу Вам пример с IPTABLES
1 действие - проброс портов на хост 192.168.1.230
2 действие - исходящий НАТ для пакетов 25,465 и тд для хоста 192.168.1.230 на интерфейсе tun100 адресом 10.10.100.2

:PREROUTING ACCEPT [0:0]
-A PREROUTING -d 37.XXX.XX.XX -p tcp -m multiport --destination-port 25,465,587,993 -j DNAT --to-destination 192.168.1.230
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o tun100 -p tcp -m multiport --destination-port 25,465,587,993 -d 192.168.1.230 -j SNAT --to-source 10.10.100.2

Konstanti

@HelpUser На сервере нет файрвола для блокирования доступа с неавторизированных ip ?
Обычно сброс соединения говорит о том , что порт закрыт

HelpUser

@Konstanti нету, больше скажу, как писал выше, на месте pfsense, использовал ideco smb, microtic, ну и не без чистого iptables. Все работает.

HelpUser

@Konstanti ну так и есть.

19:36:01.898300 IP (tos 0x0, ttl 127, id 20080, offset 0, flags [DF], proto TCP (6), length 48)
10.10.10.50.5614 > 10.10.10.19.9090: Flags [S], cksum 0x8a30 (correct), seq 830293417, win 8192, options [mss 1460,nop,nop,sackOK], length 0
19:36:01.898341 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.19.9090 > 10.10.10.50.5614: Flags [R.], cksum 0xd6e0 (correct), seq 0, ack 830293418, win 0, length 0
19:36:01.903365 IP (tos 0x0, ttl 127, id 20081, offset 0, flags [DF], proto TCP (6), length 48)
10.10.10.50.22176 > 10.10.10.19.9090: Flags [S], cksum 0x0f8c (correct), seq 3209687496, win 8192, options [mss 1460,nop,nop,sackOK], length 0
19:36:01.903405 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.19.9090 > 10.10.10.50.22176: Flags [R.], cksum 0x5c3c (correct), seq 0, ack 3209687497, win 0, length 0
19:36:02.149223 IP (tos 0x0, ttl 127, id 20082, offset 0, flags [DF], proto TCP (6), length 48)
10.10.10.50.30869 > 10.10.10.19.9090: Flags [S], cksum 0xdc75 (correct), seq 1433234636, win 8192, options [mss 1460,nop,nop,sackOK], length 0
19:36:02.149259 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.19.9090 > 10.10.10.50.30869: Flags [R.], cksum 0x2926 (correct), seq 0, ack 1433234637, win 0, length 0

Konstanti

@HelpUser Можете показать вывод команды из консоли
ifconfig -m
на PFSense

HelpUser

@Konstanti said in TCP Retransmission нет доступа к серверу:

ifconfig -m

[2.4.4-RELEASE][root@pfSense.localdomain]/root: ifconfig -m
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>
ether 2e:ca:d7:59:74:55
hwaddr 2e:ca:d7:59:74:55
inet6 fe80::2cca:d7ff:fe59:7455%vtnet0 prefixlen 64 scopeid 0x1
inet БелыйИПпровайдера netmask 0xffffff00 broadcast Провайдер.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T <full-duplex>
status: active
supported media:
media 10Gbase-T mediaopt full-duplex
vtnet1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>
ether e2:08:58:26:b9:44
hwaddr e2:08:58:26:b9:44
inet6 fe80::1:1%vtnet1 prefixlen 64 scopeid 0x2
inet 10.10.10.50 netmask 0xffffff00 broadcast 10.10.10.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T <full-duplex>
status: active
supported media:
media 10Gbase-T mediaopt full-duplex
enc0: flags=0<> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
capabilities=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
pflog0: flags=100<PROMISC> metric 0 mtu 33160
groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
syncpeer: 224.0.0.240 maxupd: 128 defer: on
syncok: 1

Konstanti

@HelpUser Странно все это
Попробуйте запустить tcpdump на lan интерфейсе PFSense , а потом в WireShark-е посмотреть , нет ли ошибок tcp пакетов ?
На данный момент у Вас включен расчет контрольных сумм пакета на уровне адаптера, а не ядром (возможно , все-таки , что в этом проблема)
можно еще увидеть вывод команды
sysctl -a | grep hw.vtnet

HelpUser

@Konstanti said in TCP Retransmission нет доступа к серверу:

sysctl -a | grep hw.vtnet

с pfsense

[2.4.4-RELEASE][root@pfSense.localdomain]/root: sysctl -a | grep hw.vtnet
hw.vtnet.rx_process_limit: 512
hw.vtnet.mq_max_pairs: 8
hw.vtnet.mq_disable: 0
hw.vtnet.lro_disable: 0
hw.vtnet.tso_disable: 0
hw.vtnet.csum_disable: 0spoiler

С тем правилом исходящего ната, да ошибки есть.

Если это правило выключить то только те что писал выше retransmission

Konstanti

@HelpUser Можно попробовать сделать так
Изменить значения этих переменных
hw.vtnet.lro_disable= 0
hw.vtnet.tso_disable= 0
hw.vtnet.csum_disable= 0

сделать их равными 1 и перегрузиться

вот пример того , как это сделано у меня

HelpUser

@Konstanti said in TCP Retransmission нет доступа к серверу:

hw.vtnet.lro_disable= 0
hw.vtnet.tso_disable= 0
hw.vtnet.csum_disable= 0

сделал, перезагрузил, ошибки те же.

Konstanti

@HelpUser а сделали равными 1 ???
покажите пож вывод команды
ifconfig -m vnet1
и sysctl -a | grep hw.vnet