date:20170412

12.04.2017 23:32, Eugene Grosbein пишет:

   65 discarded for bad checksums
>>>
>>> Этот счетчик растёт в то время, когда выполняются попытки установить 
>>> TCP-соедиение
>>> через туннель?
>>
>> Да. Синхронно с приходящими SYN ACK пакетами.
>> Аналогично растет вот это:
>>
>> # netstat -sp udp | grep "bad checksum"
>> 31 with bad checksum
>>
>> синхронно с приходящими UDP-пакетами.
> 
> Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.

С другой стороны, tcpdump -s0 про входящие TCP-пакеты на ng0 говорит cksum 
0x8bd2 (correct),
а это значит, что контрольная сумма у него сходится. Я склонен верить tcpdump-у 
в этом вопросе,
так что дело, вероятней, не в NAT, а всё же в ядре системы-клиента. Клиент сам 
по себе является
маршрутизатором? sysctl sysctl net.inet.ip.forwarding в студию. И заодно вывод 
ifconfig
для физического интерфейса там же.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Alexander Sheiko

Каким образом можно провести механическую и электрическую диагностику
разъема 8P8C, а также патч-корда UTP программным способом из PC ? :)
Причем одна из сторон патч-корда нам не подконтрольна.

13 апреля 2017 г., 1:43 пользователь Anton Sayetsky 
написал:

> 13 апр. 2017 г. 1:30 пользователь "Vladislav V. Prodan" <
> ad...@support.od.ua> написал:
>
> Сетевые карты vr никогда стабильностью и безупречной работой не отличались.
> Да и всегда существует проблема статики и КЗ у "медных" сетевых плат.
>
> А кто-то говорил, что сетевухи на чипе VIA Rhine хорошие? Тем не менее, я
> не вижу оснований ни для замены кабеля, ни для замены сетевой карты. Если
> же считаешь, что они есть - прошу привести конкретные аргументы, подходящие
> под указанные ТС условия. Естественно, "vr - кака" аргументом не считается.
>



-- 
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)


В письме от Чтв, 13 Апр 2017, 00:01 Irina Liakh пишет:

> Ничего не поменялось.

> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp" и
> "netstat -sp udp".

ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
сети и, потом, ещё и с другого провайдера. Ipsec в винде отключается так
(перегрузиться):

---
REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters]
"ProhibitIpSec"=dword:0001
---

(c XP клиентом такой вариант l2tp без Ipsec точно работает)

Сразу поймёте, кто виноват.

-- 
WBR, Alexander Sheiko

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Anton Sayetsky

13 апр. 2017 г. 1:30 пользователь "Vladislav V. Prodan" 
написал:

Сетевые карты vr никогда стабильностью и безупречной работой не отличались.
Да и всегда существует проблема статики и КЗ у "медных" сетевых плат.

А кто-то говорил, что сетевухи на чипе VIA Rhine хорошие? Тем не менее, я
не вижу оснований ни для замены кабеля, ни для замены сетевой карты. Если
же считаешь, что они есть - прошу привести конкретные аргументы, подходящие
под указанные ТС условия. Естественно, "vr - кака" аргументом не считается.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13 апреля 2017 г., 1:09 пользователь Anton Sayetsky 
написал:

>
>
> 13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan" <
> ad...@support.od.ua> написал
>
> Заменить сетевую карту и патч-корд есть возможность?
>
> А ещё шамана позвать в бубен постучать.
>

У вас необычные фантазии, с LOR'a набрались?

Сетевые карты vr никогда стабильностью и безупречной работой не отличались.
Да и всегда существует проблема статики и КЗ у "медных" сетевых плат.



-- 
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Anton Sayetsky

13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan" 
написал

Заменить сетевую карту и патч-корд есть возможность?

А ещё шамана позвать в бубен постучать.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-13 0:31 GMT+03:00 Irina Liakh :

> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp"
> и "netstat -sp udp".
>

Заменить сетевую карту и патч-корд есть возможность?


-- 
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Thu, Apr 13, 2017 at 12:16:32AM +0700, Eugene Grosbein wrote:
> выгрузить pf и ещё раз попробовать c ipfw nat - всё должно работать.

# kldstat
Id Refs AddressSize Name
 1   19 0x8020 1fa7c38  kernel
 21 0x82221000 1fe5a3   zfs.ko
 31 0x8242 811f opensolaris.ko
 41 0x82429000 3710 ums.ko
 52 0x8242d000 2322bipfw.ko
 61 0x82451000 5bc4 ipfw_nat.ko
 71 0x82457000 dc68 libalias.ko

# ipfw show
00100 3973 384882 nat 100 ip from 192.168.12.2 to any
00101 2132 251075 nat 100 ip from any to 
65000 3354 349722 allow ip from any to any
655350  0 deny ip from any to any
# ipfw nat show config
ipfw nat 100 config log redirect_addr 192.168.12.2 


Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp" и 
"netstat -sp udp".
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Alexander Sheiko

On Wed, Apr 12, 2017 at 11:17:04PM +0300, Alexander Sheiko wrote:
> 
> Покажите pfctl -s states в момент установленного туннеля.

all udp :57871 (192.168.12.2:54002) -> :1701   
MULTIPLE:MULTIPLE

> Попробуйте поменять:
> 
> nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
> 
> на
> 
> nat pass on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
Ничего не поменялось.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)


В письме от Чтв, 13 Апр 2017, 00:15 Irina Liakh пишет:

> # pfctl -s nat

Покажите pfctl -s states в момент установленного туннеля.

Попробуйте поменять:

nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)

на

nat pass on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)

-- 
WBR, Alexander Sheiko

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Alexander Sheiko

On Wed, Apr 12, 2017 at 09:39:26PM +0300, Alexander Sheiko wrote:
> Покажите, как именно НАТите.
> 
> Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
> часы. Может проблема с правилами, а может специфика фри.

# pfctl -s nat
nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
nat on vr0 inet from 192.168.11.0/24 to any -> (vr0:0)
nat on vr0 inet from 192.168.10.0/24 to any -> (vr0:0)


Евгений, я чуть позже сделаю через ipfw.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)


В письме от Срд, 12 Апр 2017, 22:35 Irina Liakh пишет:

> # pfctl -s rules

Покажите, как именно НАТите.

Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
часы. Может проблема с правилами, а может специфика фри.

-- 
WBR, Alexander Sheiko

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 2:35, Irina Liakh пишет:

>> Если ядро GENERIC, то есть вывод kldstat на роутере в то время,
>> когда туннель через него установлен.
> # kldstat
> Id Refs AddressSize Name
>  1   15 0x8020 1fa7c38  kernel
>  21 0x82221000 1fe5a3   zfs.ko
>  31 0x8242 811f opensolaris.ko
>  41 0x82429000 3710 ums.ko
>  51 0x8242d000 33becpf.ko

pf я не использую, ничего не подскажу.
Могу лишь попросить выгрузить pf и ещё раз попробовать c ipfw nat - всё должно 
работать.



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 07:59:38PM +0300, Oleg V. Nauman wrote:
>  И wifi роутер с NAT ?

У меня роутером FreeBSD с внутренним и внешним эзернетами.
Это когда через NAT подключаюсь.
Когда напрямую - через wifi роутер, мне неподвластный.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 11:52:19PM +0700, Eugene Grosbein wrote:
> Теперь насчет него, всё те же вопросы: ядро GENERIC?
Да.
Система FreeBSD 11.0-RELEASE-p2

> Что в loader.conf и в sysctl.conf?
В loader.conf пусто, в sysctl.conf только про acpi.

> Какая внешняя сетевая (имя драйвера)?
vr0

> Вывод ifconfig внешней сетевой и ipfw show в студию.
# ifconfig vr0
vr0: flags=8843 metric 0 mtu 1500
options=82808
ether X:X:X:X:X:X
inet X.X.X.X netmask 0xff00 broadcast X.X.X.X
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active

# ipfw show
ipfw: retrieving config failed: Protocol not available

# pfctl -s rules
#

> Если ядро GENERIC, то есть вывод kldstat на роутере в то время,
> когда туннель через него установлен.
# kldstat
Id Refs AddressSize Name
 1   15 0x8020 1fa7c38  kernel
 21 0x82221000 1fe5a3   zfs.ko
 31 0x8242 811f opensolaris.ko
 41 0x82429000 3710 ums.ko
 51 0x8242d000 33becpf.ko

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wednesday 12 April 2017 21:00:21 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> > 13.04.2017 0:43, Irina Liakh пишет:
> > > tcpdump вдогонку показывала,
> > 
> > Но без командной строки (без аргументов), а это важно.
> > Нужна полная команда и её вывод подряд. Не забыть ключи tcpdump -vnps0 и
> > -i.
> # tcpdump -i ng0 -nvv -s0 host 8.8.8.8
> tcpdump: listening on ng0, link-type NULL (BSD loopback), capture size 65535
> bytes
> 
> 18:14:32.026819 IP (tos 0x0, ttl 47, id 43783, offset 0, flags [none], proto
> TCP (6), length 60) 8.8.8.8.53 > 10.1.10.35.19622: Flags [S.], cksum 0x8bd2
> (correct), seq 2705699001, ack 1100352957, win 42408, options [mss
> 1380,sackOK,TS val 191452110 ecr 27279500,nop,wscale 7], length 0
> 18:14:33.248339 IP (tos 0x10, ttl 64, id 53661, offset 0, flags [DF], proto
> TCP (6), length 60) 10.1.10.35.32320 > 8.8.8.8.53: Flags [S], cksum 0x687d
> (correct), seq 3826082216, win 65535, options [mss 1356,nop,wscale
> 6,sackOK,TS val 27300588 ecr 0], length 0 18:14:33.311649 IP (tos 0x0, ttl
> 47, id 50242, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53
> > 10.1.10.35.32320: Flags [S.], cksum 0x2307 (correct), seq 3492863450, ack
> 3826082217, win 42408, options [mss 1380,sackOK,TS val 795394607 ecr
> 27300588,nop,wscale 7], length 0 18:14:33.611997 IP (tos 0x0, ttl 47, id
> 50422, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53 >
> 10.1.10.35.32320: Flags [S.], cksum 0x21db (correct), seq 3492863450, ack
> 3826082217, win 42408, options [mss 1380,sackOK,TS val 795394907 ecr
> 27300588,nop,wscale 7], length 0 18:14:35.611427 IP (tos 0x0, ttl 47, id
> 51708, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53 >
> 10.1.10.35.32320: Flags [S.], cksum 0x1a0b (correct), seq 3492863450, ack
> 3826082217, win 42408, options [mss 1380,sackOK,TS val 795396907 ecr
> 27300588,nop,wscale 7], length 0 18:14:36.248404 IP (tos 0x10, ttl 64, id
> 53666, offset 0, flags [DF], proto TCP (6), length 60) 10.1.10.35.32320 >
> 8.8.8.8.53: Flags [S], cksum 0x5cc4 (correct), seq 3826082216, win 65535,
> options [mss 1356,nop,wscale 6,sackOK,TS val 27303589 ecr 0], length 0
> 18:14:36.311682 IP (tos 0x0, ttl 47, id 52098, offset 0, flags [none],
> proto TCP (6), length 60) 8.8.8.8.53 > 10.1.10.35.32320: Flags [S.], cksum
> 0x174f (correct), seq 3492863450, ack 3826082217, win 42408, options [mss
> 1380,sackOK,TS val 795397607 ecr 27300588,nop,wscale 7], length 0
> 
> 
> "-p" же не принципиально?
> 
> > Ядро GENERIC или нет? В /boot/loader.conf и /etc/sysctl.conf есть
> > недефолтные настройки?
> Да, GENERIC.
> В /boot/loader.conf только относящееся к wpi. В /etc/sysctl.conf пусто.

 И wifi роутер с NAT ?


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 2:07, Irina Liakh пишет:

> Пробовались ipfw и pf - результат одинаковый (только на счетчики bad checksum 
> не смотрела
> во время эксперимента с ipfw).
> Портит не по причине моих рук? Значит, send-pr?

Рано, роутер с NAT тоже легко неправильно настроить.

Теперь насчет него, всё те же вопросы: ядро GENERIC?
Что в loader.conf и в sysctl.conf?
Какая внешняя сетевая (имя драйвера)?
Вывод ifconfig внешней сетевой и ipfw show в студию.
Если ядро GENERIC, то есть вывод kldstat на роутере в то время,
когда туннель через него установлен.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 07:39:25PM +0300, Vladislav V. Prodan wrote:
> Или сетевая карта (в виртуалке).

не виртуальная машина, обычная)
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 11:32:10PM +0700, Eugene Grosbein wrote:
> 13.04.2017 1:48, Irina Liakh пишет:
> > On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> >>>   65 discarded for bad checksums
> >>
> >> Этот счетчик растёт в то время, когда выполняются попытки установить 
> >> TCP-соедиение
> >> через туннель?
> > 
> > Да. Синхронно с приходящими SYN ACK пакетами.
> > Аналогично растет вот это:
> > 
> > # netstat -sp udp | grep "bad checksum"
> > 31 with bad checksum
> > 
> > синхронно с приходящими UDP-пакетами.
> 
> Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.
> В качестве NAT используется pf?

Пробовались ipfw и pf - результат одинаковый (только на счетчики bad checksum 
не смотрела
во время эксперимента с ipfw).
Портит не по причине моих рук? Значит, send-pr?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

12 апреля 2017 г., 19:32 пользователь Eugene Grosbein 
написал:

> Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.
>

Или сетевая карта (в виртуалке).


-- 
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 1:48, Irina Liakh пишет:
> On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
>>>   65 discarded for bad checksums
>>
>> Этот счетчик растёт в то время, когда выполняются попытки установить 
>> TCP-соедиение
>> через туннель?
> 
> Да. Синхронно с приходящими SYN ACK пакетами.
> Аналогично растет вот это:
> 
> # netstat -sp udp | grep "bad checksum"
> 31 with bad checksum
> 
> синхронно с приходящими UDP-пакетами.

Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.
В качестве NAT используется pf?



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> >   65 discarded for bad checksums
> 
> Этот счетчик растёт в то время, когда выполняются попытки установить 
> TCP-соедиение
> через туннель?

Да. Синхронно с приходящими SYN ACK пакетами.
Аналогично растет вот это:

# netstat -sp udp | grep "bad checksum"
31 with bad checksum

синхронно с приходящими UDP-пакетами.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 1:30, Irina Liakh пишет:

>   65 discarded for bad checksums

Этот счетчик растёт в то время, когда выполняются попытки установить 
TCP-соедиение
через туннель?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже нет?

Перепробовала несколько разных сервисов (по TCP) на разных серверах -
все ведут себя аналогично.
То же самое с разными DNS-серверами (по UDP).
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> В студию вывод команд uptime и netstat -sp tcp

# uptime
 7:05PM  up  8:26, 7 users, load averages: 0.40, 0.36, 0.29

# netstat -sp tcp
tcp:
47279 packets sent
21066 data packets (4318440 bytes)
55 data packets (15908 bytes) retransmitted
3 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
24940 ack-only packets (8996 delayed)
0 URG only packets
0 window probe packets
86 window update packets
1132 control packets
54765 packets received
19677 acks (for 4300041 bytes)
5904 duplicate acks
0 acks for unsent data
39298 packets (18835708 bytes) received in-sequence
65 completely duplicate packets (30637 bytes)
1 old duplicate packet
0 packets with some dup. data (0 bytes duped)
289 out-of-order packets (227097 bytes)
0 packets (0 bytes) of data after window
0 window probes
9 window update packets
74 packets received after close
65 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
580 connection requests
0 connection accepts
0 bad connection attempts
0 listen queue overflows
0 ignored RSTs in the windows
568 connections established (including accepts)
574 connections closed (including 12 drops)
477 connections updated cached RTT on close
478 connections updated cached RTT variance on close
35 connections updated cached ssthresh on close
4 embryonic connections dropped
18671 segments updated rtt (of 17914 attempts)
148 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
5632 keepalive timeouts
5622 keepalive probes sent
10 connections dropped by keepalive
6264 correct ACK header predictions
28170 correct data packet header predictions
0 syncache entries added
0 retransmitted
0 dupsyn
0 dropped
0 completed
0 bucket overflow
0 cache overflow
0 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
0 cookies sent
0 cookies received
128 hostcache entries added
0 bucket overflow
1 SACK recovery episode
1 segment rexmit in SACK recovery episodes
44 byte rexmits in SACK recovery episodes
20 SACK options (SACK blocks) received
219 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
0 packets with ECN CE bit set
0 packets with ECN ECT(0) bit set
0 packets with ECN ECT(1) bit set
0 successful ECN handshakes
0 times ECN reduced the congestion window
0 packets with valid tcp-md5 signature received
0 packets with invalid tcp-md5 signature received
0 packets with tcp-md5 signature mismatch
0 packets with unexpected tcp-md5 signature received
0 packets without expected tcp-md5 signature received

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

12 апреля 2017 г., 3:38 пользователь Irina Liakh  написал:

> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
> к VPN-серверу.
>


Машина в виртуалке? Какой драйвер сетевухи?

-- 
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 1:00, Irina Liakh пишет:

> "-p" же не принципиально?

В данном случае не должно быть, но tcpdump лучше всегда запускать с -p, за 
исключением
тех случаев, когда есть особая причина использовать promiscuous mode.

TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже нет?

>> Ядро GENERIC или нет? В /boot/loader.conf и /etc/sysctl.conf есть 
>> недефолтные настройки?
> Да, GENERIC.
> В /boot/loader.conf только относящееся к wpi. В /etc/sysctl.conf пусто.

В студию вывод команд uptime и netstat -sp tcp


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

Может, это окажется полезным: если в настройках изменить исключительно
тип линка (в mpd.conf вместо l2tp поставить pptp), то все работает.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> 13.04.2017 0:43, Irina Liakh пишет:
> 
> > tcpdump вдогонку показывала,
> 
> Но без командной строки (без аргументов), а это важно.
> Нужна полная команда и её вывод подряд. Не забыть ключи tcpdump -vnps0 и -i.

# tcpdump -i ng0 -nvv -s0 host 8.8.8.8
tcpdump: listening on ng0, link-type NULL (BSD loopback), capture size 65535 
bytes

18:14:32.026819 IP (tos 0x0, ttl 47, id 43783, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.19622: Flags [S.], cksum 0x8bd2 (correct), seq 
2705699001, ack 1100352957, win 42408, options [mss 1380,sackOK,TS val 
191452110 ecr 27279500,nop,wscale 7], length 0
18:14:33.248339 IP (tos 0x10, ttl 64, id 53661, offset 0, flags [DF], proto TCP 
(6), length 60)
10.1.10.35.32320 > 8.8.8.8.53: Flags [S], cksum 0x687d (correct), seq 
3826082216, win 65535, options [mss 1356,nop,wscale 6,sackOK,TS val 27300588 
ecr 0], length 0
18:14:33.311649 IP (tos 0x0, ttl 47, id 50242, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.32320: Flags [S.], cksum 0x2307 (correct), seq 
3492863450, ack 3826082217, win 42408, options [mss 1380,sackOK,TS val 
795394607 ecr 27300588,nop,wscale 7], length 0
18:14:33.611997 IP (tos 0x0, ttl 47, id 50422, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.32320: Flags [S.], cksum 0x21db (correct), seq 
3492863450, ack 3826082217, win 42408, options [mss 1380,sackOK,TS val 
795394907 ecr 27300588,nop,wscale 7], length 0
18:14:35.611427 IP (tos 0x0, ttl 47, id 51708, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.32320: Flags [S.], cksum 0x1a0b (correct), seq 
3492863450, ack 3826082217, win 42408, options [mss 1380,sackOK,TS val 
795396907 ecr 27300588,nop,wscale 7], length 0
18:14:36.248404 IP (tos 0x10, ttl 64, id 53666, offset 0, flags [DF], proto TCP 
(6), length 60)
10.1.10.35.32320 > 8.8.8.8.53: Flags [S], cksum 0x5cc4 (correct), seq 
3826082216, win 65535, options [mss 1356,nop,wscale 6,sackOK,TS val 27303589 
ecr 0], length 0
18:14:36.311682 IP (tos 0x0, ttl 47, id 52098, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.32320: Flags [S.], cksum 0x174f (correct), seq 
3492863450, ack 3826082217, win 42408, options [mss 1380,sackOK,TS val 
795397607 ecr 27300588,nop,wscale 7], length 0


"-p" же не принципиально?

> Ядро GENERIC или нет? В /boot/loader.conf и /etc/sysctl.conf есть недефолтные 
> настройки?
Да, GENERIC.
В /boot/loader.conf только относящееся к wpi. В /etc/sysctl.conf пусто.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

13.04.2017 0:43, Irina Liakh пишет:

>> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми 
>> аргументами,
>> даже если кажется, что это не нужно - на самом деле, нужно.
> На клиенте ipfw, pf и ipfilter не загружены, на сервере с NAT'ом
> загружен только pf с nat rules, фильтрующих правил нет.
> tcpdump вдогонку показывала,

Но без командной строки (без аргументов), а это важно.
Нужна полная команда и её вывод подряд. Не забыть ключи tcpdump -vnps0 и -i.

> ifconfig ng0 вот:
> 
> ng0: flags=88d1 metric 0 mtu 
> 1396
> inet 10.1.10.35 --> 10.1.110.254 netmask 0x 
> nd6 options=29
> 
>> А по существу - входящие пакеты дропаются. Если tcpdump -s0 видит входящие
>> пакеты на ngX с верными контрольными суммами, то первый подозреваемый - 
>> пакетный фильтр.
>> Разница "с NAT" и "без нат" может быть в чём угодно, например некорректные
>> правила файрвола, не учитывающие изменения имени интерфейса при смене схемы.
>> Ну или что угодно ещё.
> Имя интерфейса всегда ng0.
> А что еще? Я постаралась сделать схему предельно простую, но может что-то 
> упустила?

Ядро GENERIC или нет? В /boot/loader.conf и /etc/sysctl.conf есть недефолтные 
настройки?


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 09:37:37PM +0700, Eugene Grosbein wrote:
> Стандартная ошибка - художественное изложение своими словами проделанной
> диагностики и полное отсутствие по-настоящему необходимых деталей.
> Не надо так.
угу.

> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми аргументами,
> даже если кажется, что это не нужно - на самом деле, нужно.
На клиенте ipfw, pf и ipfilter не загружены, на сервере с NAT'ом
загружен только pf с nat rules, фильтрующих правил нет.
tcpdump вдогонку показывала, ifconfig ng0 вот:

ng0: flags=88d1 metric 0 mtu 
1396
inet 10.1.10.35 --> 10.1.110.254 netmask 0x 
nd6 options=29

> А по существу - входящие пакеты дропаются. Если tcpdump -s0 видит входящие
> пакеты на ngX с верными контрольными суммами, то первый подозреваемый - 
> пакетный фильтр.
> Разница "с NAT" и "без нат" может быть в чём угодно, например некорректные
> правила файрвола, не учитывающие изменения имени интерфейса при смене схемы.
> Ну или что угодно ещё.
Имя интерфейса всегда ng0.
А что еще? Я постаралась сделать схему предельно простую, но может что-то 
упустила?
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

12.04.2017 7:38, Irina Liakh пишет:
> Добрый день всем!
> 
> Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> известно)
> 
> Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
> к VPN-серверу.
> Туннель поднимается, в логах все ок. Но по туннелю не ходят TCP и UDP
> (пинги ходят).  При попытке установить TCP-соединение с этой машины,
> tcpdump показывает исходящий SYN, входящий SYN ACK, но исходящего ACK нету,
> как будто не воспринимается SYN ACK. Через время повторно уходит SYN и т.д.
> С UDP похожая ситуация. Например, если запустить команду "host ...",
> tcpdump показывает исходящие DNS-запросы, приходящие DNS-ответы,
> но команда выдает:
> 
> # host google.com 8.8.8.8
> ;; connection timed out; no servers could be reached
> 
> В качестве NAT'а пробовались pf и ipfw, результат одинаковый.
> Если подключить машину не через NAT, то все работает.
> Система FreeBSD 10.3-RELEASE-p11 (пробовалась и 11.0), на сервере с NAT'ом -
> FreeBSD 11.0.
> 
> Почему туннель не работает через NAT?

Стандартная ошибка - художественное изложение своими словами проделанной
диагностики и полное отсутствие по-настоящему необходимых деталей.
Не надо так.

Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми аргументами,
даже если кажется, что это не нужно - на самом деле, нужно.

А по существу - входящие пакеты дропаются. Если tcpdump -s0 видит входящие
пакеты на ngX с верными контрольными суммами, то первый подозреваемый - 
пакетный фильтр.
Разница "с NAT" и "без нат" может быть в чём угодно, например некорректные
правила файрвола, не учитывающие изменения имени интерфейса при смене схемы.
Ну или что угодно ещё.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 04:04:35PM +0300, Oleg V. Nauman wrote:
>  SYN+ACK похож на правду, значит еще один вариант - смотреть а не уходит ли 
> ACK мимо туннеля или вообще через "левый" интерфейс.

Посмотрела "для очистки совести" - не уходит.
Видимо, дело не в "левом" интерфейсе, т.к. в случае DNS-запросов UDP-пакеты
ходят как положено по туннелю, но пришедший ответ (штатно расшифровываемый
tcpdump'ом) где-то застряет потом.
Наверное, аналогичным образом застряют и приходящие SYN ACK.
Может, это что-то с ng_l2tp? К сож, нет возможности засесть за него.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wednesday 12 April 2017 16:17:52 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
> >  Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это
> >  момент.
> Серверная сторона туннеля мне не доступна. Доступны только клиентская
> и сервер-роутер, который маскарадит клиентскую машину и роутит ее к
> VPN-серверу. Да и смысл смотреть на серверной?

 Для очистки совести.

> К клиенту приходит валидный вроде) пакет, клиентская машина почему-то
> не отвечает.
> 
> Кусочек tcpdump-а (на клиенте) с UDP уже приводила:
> 
> 13:44:39.059956 IP (tos 0x0, ttl 64, id 18546, offset 0, flags [none], proto
> UDP (17), length 56) 10.1.10.35.44223 > 8.8.8.8.53: [udp sum ok] 55910+ A?
> google.com. (28) 13:44:39.122582 IP (tos 0x0, ttl 47, id 31302, offset 0,
> flags [none], proto UDP (17), length 72) 8.8.8.8.53 > 10.1.10.35.44223:
> [udp sum ok] 55910 q: A? google.com. 1/0/0 google.com. A 172.217.20.174
> (44)
> 
> (и так два раза с промежутком в 5 секунд)
> 
> > В принципе даже лучше вместо host использовать telnet 8.8.8.8 53 на
> > клиенте.
> Вот (это на клиенте):
> 
> 13:39:02.631811 IP (tos 0x10, ttl 64, id 17539, offset 0, flags [DF], proto
> TCP (6), length 60) 10.1.10.35.45856 > 8.8.8.8.53: Flags [S], cksum 0xce30
> (correct), seq 3572634596, win 65535, options [mss 1356,nop,wscale
> 6,sackOK,TS val 10769972 ecr 0], length 0 13:39:02.693085 IP (tos 0x0, ttl
> 47, id 61491, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53
> > 10.1.10.35.45856: Flags [S.], cksum 0x6b98 (correct), seq 2114486942, ack
> 3572634597, win 42408, options [mss 1356,sackOK,TS val 660903122 ecr
> 10769972,nop,wscale 7], length 0 13:39:02.993795 IP (tos 0x0, ttl 47, id
> 61713, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53 >
> 10.1.10.35.45856: Flags [S.], cksum 0x6a6c (correct), seq 2114486942, ack
> 3572634597, win 42408, options [mss 1356,sackOK,TS val 660903422 ecr
> 10769972,nop,wscale 7], length 0 13:39:04.992800 IP (tos 0x0, ttl 47, id
> 62832, offset 0, flags [none], proto TCP (6), length 60) 8.8.8.8.53 >
> 10.1.10.35.45856: Flags [S.], cksum 0x629c (correct), seq 2114486942, ack
> 3572634597, win 42408, options [mss 1356,sackOK,TS val 660905422 ecr
> 10769972,nop,wscale 7], length 0
> 
> (и так сэм раз, ну или сколько там у telnet ретраев). Гугль, оказывается, аж
> три SYN ACK подряд шлет, другие опробованные серверы - один.

 SYN+ACK похож на правду, значит еще один вариант - смотреть а не уходит ли 
ACK мимо туннеля или вообще через "левый" интерфейс.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
> 
>  Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это момент.

Серверная сторона туннеля мне не доступна. Доступны только клиентская
и сервер-роутер, который маскарадит клиентскую машину и роутит ее к VPN-серверу.
Да и смысл смотреть на серверной? К клиенту приходит валидный (вроде) пакет,
клиентская машина почему-то не отвечает.

Кусочек tcpdump-а (на клиенте) с UDP уже приводила:

13:44:39.059956 IP (tos 0x0, ttl 64, id 18546, offset 0, flags [none], proto 
UDP (17), length 56)
10.1.10.35.44223 > 8.8.8.8.53: [udp sum ok] 55910+ A? google.com. (28)
13:44:39.122582 IP (tos 0x0, ttl 47, id 31302, offset 0, flags [none], proto 
UDP (17), length 72)
8.8.8.8.53 > 10.1.10.35.44223: [udp sum ok] 55910 q: A? google.com. 1/0/0 
google.com. A 172.217.20.174 (44)

(и так два раза с промежутком в 5 секунд)

> В принципе даже лучше вместо host использовать telnet 8.8.8.8 53 на клиенте.

Вот (это на клиенте):

13:39:02.631811 IP (tos 0x10, ttl 64, id 17539, offset 0, flags [DF], proto TCP 
(6), length 60)
10.1.10.35.45856 > 8.8.8.8.53: Flags [S], cksum 0xce30 (correct), seq 
3572634596, win 65535, options [mss 1356,nop,wscale 6,sackOK,TS val 10769972 
ecr 0], length 0
13:39:02.693085 IP (tos 0x0, ttl 47, id 61491, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.45856: Flags [S.], cksum 0x6b98 (correct), seq 
2114486942, ack 3572634597, win 42408, options [mss 1356,sackOK,TS val 
660903122 ecr 10769972,nop,wscale 7], length 0
13:39:02.993795 IP (tos 0x0, ttl 47, id 61713, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.45856: Flags [S.], cksum 0x6a6c (correct), seq 
2114486942, ack 3572634597, win 42408, options [mss 1356,sackOK,TS val 
660903422 ecr 10769972,nop,wscale 7], length 0
13:39:04.992800 IP (tos 0x0, ttl 47, id 62832, offset 0, flags [none], proto 
TCP (6), length 60)
8.8.8.8.53 > 10.1.10.35.45856: Flags [S.], cksum 0x629c (correct), seq 
2114486942, ack 3572634597, win 42408, options [mss 1356,sackOK,TS val 
660905422 ecr 10769972,nop,wscale 7], length 0

(и так сэм раз, ну или сколько там у telnet ретраев). Гугль, оказывается, аж 
три SYN ACK подряд шлет,
другие опробованные серверы - один.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wednesday 12 April 2017 15:00:43 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> > Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
> > отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?
> 
> Не растут. Кстати, UDP sum ok:
> 
> 12:35:11.991026 IP (tos 0x0, ttl 64, id 13540, offset 0, flags [none], proto
> UDP (17), length 56) 10.1.10.35.42370 >
> google-public-dns-a.google.com.domain: [udp sum ok] 16907+ A? google.com.
> (28) 12:35:12.053594 IP (tos 0x0, ttl 47, id 29674, offset 0, flags [none],
> proto UDP (17), length 72) google-public-dns-a.google.com.domain >
> 10.1.10.35.42370: [udp sum ok] 16907 q: A? google.com. 1/0/0 google.com. A
> 172.217.20.174 (44)

 Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это момент.
В принципе даже лучше вместо host использовать telnet 8.8.8.8 53 на клиенте.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> Либо пакеты приходят на клиент "поврежденные" (crc), поэтому 
> отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?

Не растут. Кстати, UDP sum ok:

12:35:11.991026 IP (tos 0x0, ttl 64, id 13540, offset 0, flags [none], proto 
UDP (17), length 56)
10.1.10.35.42370 > google-public-dns-a.google.com.domain: [udp sum ok] 
16907+ A? google.com. (28)
12:35:12.053594 IP (tos 0x0, ttl 47, id 29674, offset 0, flags [none], proto 
UDP (17), length 72)
google-public-dns-a.google.com.domain > 10.1.10.35.42370: [udp sum ok] 
16907 q: A? google.com. 1/0/0 google.com. A 172.217.20.174 (44)

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность roman

On 12.04.17 11:01, skeletor wrote:

12.04.17 03:38, Irina Liakh пишет:

Добрый день всем!

Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)

Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим
выход

к VPN-серверу.
Туннель поднимается, в логах все ок. Но по туннелю не ходят TCP и UDP
(пинги ходят). При попытке установить TCP-соединение с этой машины,
tcpdump показывает исходящий SYN, входящий SYN ACK, но исходящего ACK
нету,
как будто не воспринимается SYN ACK. Через время повторно уходит SYN
и т.д.

С UDP похожая ситуация. Например, если запустить команду "host ...",
tcpdump показывает исходящие DNS-запросы, приходящие DNS-ответы,
но команда выдает:

# host google.com 8.8.8.8
;; connection timed out; no servers could be reached

В качестве NAT'а пробовались pf и ipfw, результат одинаковый.
Если подключить машину не через NAT, то все работает.
Система FreeBSD 10.3-RELEASE-p11 (пробовалась и 11.0), на сервере с
NAT'ом -

FreeBSD 11.0.

Почему туннель не работает через NAT?
___

Если туннель поднимается, то НАТ здесь уже не причём. Все остальные
пакеты ходят уже внутри туннеля. И здесь, либо mtu, либо файервол
(может быть как на клиенте так и не серверной стороне).
Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wed, Apr 12, 2017 at 11:38:20AM +0300, Oleg V. Nauman wrote:
>  Часы убежали вперед.
Спасибо :) Спрошу почему так.

> > On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > > линии присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы
> > > хост полностью на время эксперимента...
> > Это при отключенном файерволе на машине с mpd и на сервере с NAT.
> 
>  Если нет ACK на SYN ACK, то предположу что где-то спрятался маскарад на 
> клиенте.

Нету на клиенте маскарада. Пруф - tcpdump на сервере с NAT.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

On Wednesday 12 April 2017 13:27:42 Irina Liakh wrote:

 Часы убежали вперед.

> On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > линии присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы
> > хост полностью на время эксперимента...
> Это при отключенном файерволе на машине с mpd и на сервере с NAT.

 Если нет ACK на SYN ACK, то предположу что где-то спрятался маскарад на 
клиенте.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность Alexander Bolshakov

On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> 
> Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в 
> линии присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост 
> полностью на время эксперимента...

Это при отключенном файерволе на машине с mpd и на сервере с NAT.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)

2017-04-12 Пенетрантность skeletor

12.04.17 03:38, Irina Liakh пишет:

Добрый день всем!

Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)

Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
к VPN-серверу.
Туннель поднимается, в логах все ок. Но по туннелю не ходят TCP и UDP
(пинги ходят). При попытке установить TCP-соединение с этой машины,
tcpdump показывает исходящий SYN, входящий SYN ACK, но исходящего ACK нету,
как будто не воспринимается SYN ACK. Через время повторно уходит SYN и т.д.
С UDP похожая ситуация. Например, если запустить команду "host ...",
tcpdump показывает исходящие DNS-запросы, приходящие DNS-ответы,
но команда выдает:

# host google.com 8.8.8.8
;; connection timed out; no servers could be reached

Почему туннель не работает через NAT?
___

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)


Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в линии 
присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост 
полностью на время эксперимента...
--
Отправлено из Mail.Ru для Android среда, 12 апреля 2017г., 10:49 +03:00 от 
Irina Liakh  sp...@itl.ua :

>On Wed, Apr 12, 2017 at 06:29:29AM +0300, Vladislav V. Prodan wrote:
>> 12 апреля 2017 г., 3:38 пользователь Irina Liakh < sp...@itl.ua > написал:
>> 
>> > Добрый день всем!
>> >
>> > Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
>> > известно)
>> >
>> 
>> Смотреть с каким MTU поднялся туннель на обоих концах.
>> Подбирая пингом размер пакетов, вычисляем  MTU.
>> 
>> На клиенте и на сервере, в конфиге mpd,  не забываем ставить опцию
>> set iface enable tcpmssfix
>
>Пробовала, не помогло.
>
>> 
>> На сервере в конфиге mpd, в особо тяжелом случае придется ручками
>> выставлять что-то подобное:
>> set link mtu 1464
>> set link mru 1464
>
>Вроде как это ни при чем, но тоже пробовала) Не проходят небольшие пакеты,
>они не упираются в mtu/mru.
>___
>freebsd mailing list
>freebsd@uafug.org.ua
>http://mailman.uafug.org.ua/mailman/listinfo/freebsd
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] l2tp за NAT'ом (без IPSEC)