OpenVPN подключается, но ничего не пингует

werter

Доброе.
Что с NAT на openwrt касательно openvpn-туннеля ? Что с правилами fw на openwrt касательно openvpn-туннеля ?

Если у вас роутер какой-то из этих http://tomato.groov.pl/?page_id=69, то смените openwrt на http://tomato.groov.pl/?page_id=31
В разы функциональнее. Есть multiwan и нет проблем с OpenVPN. После перепрошивки первым делом сбросить nvram!

Если у вас что-то из этого https://bitbucket.org/padavan/rt-n56u/downloads/, то шейтесь тем, что там же и указано. Можно также скомпилировать под zyxel keenetic и др. роутеры - http://4pda.ru/forum/index.php?showtopic=714487

P.s. Существует spin-off openwrt - LEDE https://lede-project.org/toh/views/toh_fwdownload Первая, увиденная мною прошивка, на ядре 4.х (!)

AlexSYS

Еще раз проверил правила на OpenWrt - вроде все правильно…

1.png_thumb

2.png_thumb

PbIXTOP

Снимите dump с обоих концов тунеля, чтобы понять — а где же все таки происходит блокировка пакета.
А что бы пинги ходили между сетями pfSense должен тоже знать не только о 10.0.0.1, но и что за ним располагается 10.254.254.0/24

AlexSYS

Как снять dump?

PbIXTOP

Через консоль tcpdump
в pfSense есть также возможность через веб-интерфейс — Diagnostics/Packet Capture.

AlexSYS

c pfsense:


03:18:45.498046 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 868, seq 0, length 64
03:18:46.518496 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 868, seq 1, length 64
03:18:47.540215 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 868, seq 2, length 64
03:18:52.855046 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56676, seq 0, length 64
03:18:53.918033 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56676, seq 1, length 64
03:18:54.981033 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56676, seq 2, length 64
03:19:10.067602 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 20404, seq 0, length 64
03:19:11.071987 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 20404, seq 1, length 64
03:19:12.125781 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 20404, seq 2, length 64

на openwrt нет tcpdump, попробую поставить

AlexSYS

аналогично на openwrt:


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:25:06.351050 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2107, seq 0, length 64
09:25:06.532622 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2111, seq 0, length 64
09:25:07.351689 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2107, seq 1, length 64
09:25:07.533247 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2111, seq 1, length 64
09:25:08.351970 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2107, seq 2, length 64
09:25:08.533447 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2111, seq 2, length 64
09:25:09.352186 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2107, seq 3, length 64
09:25:09.533654 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2111, seq 3, length 64
09:25:10.352391 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2107, seq 4, length 64
09:25:10.533861 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2111, seq 4, length 64
03:18:45.498046 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 868, seq 0, length 64

AlexSYS

с pfsense подробный лог


03:29:26.409909 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 30800, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.2: ICMP echo request, id 19496, seq 0, length 64
03:29:27.417648 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 29358, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.2: ICMP echo request, id 19496, seq 1, length 64
03:29:28.421933 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 16977, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.2: ICMP echo request, id 19496, seq 2, length 64
03:29:37.429739 AF IPv4 (2), length 84: (tos 0x0, ttl 127, id 610, offset 0, flags [none], proto UDP (17), length 80)

PbIXTOP

Если принять pfSense - 10.0.0.2 и openwrt - 10.0.0.1
То по дампам явно видно — что оба не принимают входящих соединений.
Попробуйте на обоих на интерфесах OpenVPN разрешить все для всех.

AlexSYS

Все ведь разрешено…

3.png_thumb

werter

А чего forward-то на vpn0 у вас reject ? Зачем проходящий через vpn-интерфейс трафик-то отбрасываете ? Там accept должен быть. Плюс nat (маскарадинг) возможно надо будет вкл. для vpn. Вот с этим разберитесь. Что-то типа https://watchmysys.com/blog/2014/05/wifi-vpn-openwrt-wr703n/

Если же вам будет необходим доступ в сеть за клиентом, то необходимо создавать впн-сервер на пф построенный на сертификатах. И править настройки опенпн Client specific overrides на пф.

P.s. Повторюсь. Вы модель своего роутера смотрели по ссылкам, что я давал ? Там с openvpn все гораздо проще.

AlexSYS

Поставил на правиле VPN-Lan accept в forward - ничего не поменялось: не пингуется ни с пф, ни с openwrt.
Насчет lede - прошивка есть (tplink 3600), но у меня около 20 маршрутизаторов на которых уже настроено переключение на резервные каналы по USB модемам. Тут вроде тоже ничего сложного c openvpn, вернее везде одинаково.

werter

Доброе.

Пробуйте http://wiki.openwrt.org/doc/howto/vpn.client.openvpn.tun

Вот всегда забываю про оф. вики :)

pigbrother

По идее openwrt - классика, и а в ней оно не может не заработать.
Недавно поднимал клиента site-to-site (но в режиме remote access+user auth, логин\пароль лишними не бывают ) на Asus c Asuswrt-Merlin. Open VPN в ней - порт с Tomato.
Кроме импорта .ovpn-конфига практически никаких настроек делать не пришлось.
Вот рабочий конфиг с Асуса:

/tmp/etc/openvpn

# Automatically generated configuration
daemon
client
dev tun11
proto tcp-client
remote 1.2.2.2  хххx
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo adaptive
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
tls-auth static.key 1
ca ca.crt
cert client.crt
key client.key
auth-user-pass up
status-version 2
status status 10

# Custom Configuration
auth SHA1
tls-client
verify-x509-name xxx-xxx-cert name
ns-cert-type server

Вот, что добавляет скрипт client1-fw.sh Асуса в iptables:
#!/bin/sh
iptables -I INPUT -i tun11 -j ACCEPT
iptables -I FORWARD 2 -i tun11 -j ACCEPT
iptables -t mangle -I PREROUTING -i tun11 -j MARK –set-mark 0x01/0x7

Вот конфиг сервера, с котрым работает Асус:

dev ovpns2
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local  1.2.2.2 
tls-server
server 10.11.10.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server2
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' true server2" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'xxx-xxx-cert' 1"
lport хххx
management /var/etc/openvpn/server2.sock unix
push "route 10.0.2.0 255.255.255.0"
ca /var/etc/openvpn/server2.ca 
cert /var/etc/openvpn/server2.cert 
key /var/etc/openvpn/server2.key 
dh /etc/dh-parameters.1024
crl-verify /var/etc/openvpn/server2.crl-verify 
tls-auth /var/etc/openvpn/server2.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
topology subnet
route 10.168.1.0 255.255.255.0

10.11.10.0 - сеть туннеля
10.0.2.0 - сеть офиса за Pfsense
10.168.1.0 - сеть за Асусом

tcp выбран сознательно

Ну и не забыть про iroute (или IPv4 Remote Network) в Open VPN-Client Specific Overrides на pfSense

werter

У ТС проблема не c установкой линка, а с правилами iptables, nat на OpenWRT.

P.s. Все же тот же Padavan куда интереснее Asuswrt-Merlin. Если железо позволяет, конечно.
http://forum.ixbt.com/topic.cgi?id=14:62022
https://bitbucket.org/padavan/rt-n56u/wiki/EN/CommonTips
http://4pda.ru/forum/index.php?showtopic=714487
https://bitbucket.org/padavan/rt-n56u/wiki/browse/RU

pigbrother

Устройство не мое, Asuswrt-Merlin - выбор его хозяина, оспаривать который субординация мне не позволяет.

Я не акцентировал ответ на предмет проблем установки линка, Subject топика говорит сам себя
Пример изменений в iptables я привел.
Пинги не ходят ни внутри туннеля, ни, тем более, между сетями.

ТС нужен site-to-site. Зачем NAT, если можно без него?

werter

NAT в OpenWRT.
Если получится и без nat - замечательно. Линк по настройке я дал. Ждем результатов от ТС.

AlexSYS

Спасибо всем участвующим. Но не фига не помогает. Уже пробовал и tun и tap, менял топологию - туннель поднимается, но пинги все также не идут.
Понятно что ковырял и iptables. Проверял по последней ссылке - все также.
Вот что в /etc/config/firewall:


config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option network 'lan'
        option forward 'REJECT'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fe80::/10'
        option src_port '547'
        option dest_ip 'fe80::/10'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config rule
        option name 'Unencrypted-CO-NET'
        option src 'lan'
        option dest 'wan'
        option dest_ip '192.168.1.0/24'
        option family 'ipv4'
        option target 'REJECT'
        option proto 'all'

config zone
        option name 'wan_3g'
        option forward 'REJECT'
        option output 'ACCEPT'
        option input 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network '3g'

config forwarding
        option dest 'wan'
        option src 'lan'

config forwarding
        option dest 'wan_3g'
        option src 'lan'

config zone
        option input 'ACCEPT'
        option output 'ACCEPT'
        option network 'vpn0'
        option name 'vpn'
        option forward 'ACCEPT'
        option masq '1'

config forwarding
        option dest 'lan'
        option src 'vpn'

config forwarding
        option dest 'vpn'
        option src 'lan'

ifconfig:


3g-3g     Link encap:Point-to-Point Protocol
          inet addr:100.65.68.191  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:825 errors:0 dropped:0 overruns:0 frame:0
          TX packets:863 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:109792 (107.2 KiB)  TX bytes:102232 (99.8 KiB)

br-lan    Link encap:Ethernet  HWaddr 14:CC:20:48:8F:DC
          inet addr:10.254.254.1  Bcast:10.254.254.255  Mask:255.255.255.0
          inet6 addr: fe80::16cc:20ff:fe48:8fdc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3004 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3315 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:353452 (345.1 KiB)  TX bytes:689049 (672.8 KiB)

eth0      Link encap:Ethernet  HWaddr 14:CC:20:48:8F:DC
          inet6 addr: fe80::16cc:20ff:fe48:8fdc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3217 errors:0 dropped:7 overruns:0 frame:0
          TX packets:3997 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:433092 (422.9 KiB)  TX bytes:890725 (869.8 KiB)
          Interrupt:4

eth0.1    Link encap:Ethernet  HWaddr 14:CC:20:48:8F:DC
          UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:3192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:373022 (364.2 KiB)  TX bytes:682475 (666.4 KiB)

eth0.2    Link encap:Ethernet  HWaddr 14:CC:20:48:8F:DC
          inet6 addr: fe80::16cc:20ff:fe48:8fdc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:727 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:189694 (185.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1073 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1073 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:82180 (80.2 KiB)  TX bytes:82180 (80.2 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.0.6  P-t-P:10.0.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:420 (420.0 B)

route:


default         10.64.64.64     0.0.0.0         UG    0      0        0 3g-3g
10.0.0.1        10.0.0.5        255.255.255.255 UGH   0      0        0 tun0
10.0.0.5        *               255.255.255.255 UH    0      0        0 tun0
10.64.64.64     *               255.255.255.255 UH    0      0        0 3g-3g
10.254.254.0    *               255.255.255.0   U     0      0        0 br-lan
192.168.100.0   10.0.0.5        255.255.255.0   UG    0      0        0 tun0

При всем при этом, на том же pfsense корректно работает другой Openvpn сервер на другом порту, используется tls user/pass, но клиент под виндой, таким образом запускал через импорт ovpn. На проблемном сервере-клиенте использую p12.

werter

Доброе.

Вот это зачем ?

config rule
        option name 'Unencrypted-CO-NET'
        option src 'lan'
        option dest 'wan'
        option dest_ip '192.168.1.0/24'
        option family 'ipv4'
        option target 'REJECT'
        option proto 'all'

Попробуйте уйти от адресации 10.x.x.x в туннельной сети. Смените на 172.16.х.х, напр.

AlexSYS

Лишнее правило убрал, сеть поменял. Без изменений.

Если запускаю пинги openwrt до pfsense, то на pfsense Bytes Recived увеличивается - вообще не ясно.