Pfsense: Ipsec vti
-
Вы имеете доступ ко второму участника туннеля ???
Какая версия Pf ? Есть одно проприетарное решение для таких случаев .... -
@Konstanti да, есть доступ
Version 2.7.2-RELEASE (amd64)
на левой стороне ubuntu c strongswan -
я бы рекомендовал с той стороны смотреть , что происходит
у меня так туннель настроен с Испанией ( GRE over IPsec ) и все работает , как мне надо ( Centos)
я написал свой собственный модуль ядра ( есть версия для PF 2_7_2 ( Freebsd 14.0) , который перехватывает все DNS ответы и ищет определенные шаблоны ( например , apple , Netflix и тд и тп ) , результат - ip адреса из этих ответов отправляет в нужные мне таблицы ( Алиасы) , а потом это можно использовать в правилахкак это выглядит в результате ( на примере Netflix)
[2.4.4-RELEASE][admin@ru.xxxxxxx.org]/root: kldstat -v | grep dnsp 5 1 0xffffffff8322c000 f57a dnsp.ko (./dnsp.ko) 664 dnsp по памяти , потребляет немного dnsp_rec 74 10K - 74 128 table_rec 8 1K - 8 64 kernel_regex 303 87K - 342 16,32,64,128,256,512
смотрю Netflix
если нужна помощь , напишите , готов все настроить для тестирования (если доверяете , то мне нужен будет доступ к консоли PF и Web интерфейсу)
-
@Konstanti Спасибо за наводку, добавил gre и полетело)
-
@dmshel80 Не забывайте про MTU/MSS на GRE/VTI интерфейсах
- GRE over IPSEC немного криво реализован именно в PF
-
@Konstanti а какие значения необходимы? подбирать?
-
@dmshel80
я ставлю 1400 MTU / 1386 MSS для greне знаю , насколько все это корректно
но вот , пакетики бегают
tcpdump -netti igb1 host 192.168.1.34 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb1, link-type EN10MB (Ethernet), capture size 262144 bytes 1720602976.247568 00:08:a2:0a:ff:73 > 58:d3:49:e2:54:30, ethertype IPv4 (0x0800), length 1400: 84.232.79.33.443 > 192.168.1.34.60446: Flags [.], seq 3538976888:3538978222, ack 2003595699, win 2051, options [nop,nop,TS val 2428846028 ecr 3109663200], length 1334 1720602976.247899 00:08:a2:0a:ff:73 > 58:d3:49:e2:54:30, ethertype IPv4 (0x0800), length 1400: 84.232.79.33.443 > 192.168.1.34.60446: Flags [.], seq 1334:2668, ack 1, win 2051, options [nop,nop,TS val 2428846028 ecr 3109663200], length 1334 1720602976.247949 00:08:a2:0a:ff:73 > 58:d3:49:e2:54:30, ethertype IPv4 (0x0800), length 1400: 84.232.79.33.443 > 192.168.1.34.60446: Flags [.], seq 2668:4002, ack 1, win 2051, options [nop,nop,TS val 2428846028 ecr 3109663200], length 1334 -
@Konstanti рано радовался я ))) трасса пошла через тунель, но вот странички выдают ERR_CONNECTION_TIMED_OUT
-
@dmshel80
1 mss - через iptables настраивали ? Может быть есть и другая технология со стороны Linux ( но я так настраивал)2 tcpdump смотрите , что происходит
-
@Konstanti ip route add 10.10.10.0/24 dev tun10 advmss 1386 так задал на стороне убунты
-
-
@Konstanti ```
1720604893.427066 AF IPv4 (2), length 56: 172.19.200.1.50599 > 31.13.84.174.443: Flags [S], seq 4275518985, win 64240, options [mss 1346,nop,wscale 8,nop,nop,sackOK], length 0
1720604893.468692 AF IPv4 (2), length 56: 172.19.200.1.13825 > 31.13.84.174.443: Flags [S], seq 998540930, win 64240, options [mss 1346,nop,wscale 8,nop,nop,sackOK], length 0
1720604893.664104 AF IPv4 (2), length 33: 172.19.200.1 > 172.19.200.2: ICMP echo request, id 23760, seq 3394, length 9
1720604893.757353 AF IPv4 (2), length 33: 172.19.200.2 > 172.19.200.1: ICMP echo reply, id 23760, seq 3394, length 9
1720604894.165167 AF IPv4 (2), length 33: 172.19.200.1 > 172.19.200.2: ICMP echo request, id 23760, seq 3395, length 9
1720604894.258476 AF IPv4 (2), length 33: 172.19.200.2 > 172.19.200.1: ICMP echo reply, id 23760, seq 3395, length 9
1720604894.429298 AF IPv4 (2), length 56: 172.19.200.1.50599 > 31.13.84.174.443: Flags [S], seq 4275518985, win 64240, options [mss 1346,nop,wscale 8,nop,nop,sackOK], length 0
1720604894.431270 AF IPv4 (2), length 74: 172.19.200.1.13540 > 129.134.31.12.53: 858% [1au] A? instagram.com. (42)
1720604894.474822 AF IPv4 (2), length 56: 172.19.200.1.13825 > 31.13.84.174.443: Flags [S], seq 998540930, win 64240, options [mss 1346,nop,wscale 8,nop,nop,sackOK], length 0 -
у вас пакеты не возвращаются обратно
разбирайтесь со второй стороной ))) все ли корректно настроено
1 Nat исходящий для 172.19.200.0/24 ? -
@Konstanti Победил, не хватало iptables -A FORWARD -j ACCEPT))
