http://rpc.one.pl/index.php/lista-artyk … -a-openwrt
tu masz konkretne przykłady min. ten

pakiety przechodzą przez postrouting to fakt ale jak nie da się im ACCEPT przed MASQUERADE to będą modyfikowane przez NAT i o to mi chodziło. A ipsec ma wiadome problemy z tym. Generalnie jest obciążone tym że na początku wymagało publicznych adresów IP. Szybko okazało się że są problemy z natem bo oczywiście dostawcy nie dawali każdemu publicznego adresu IP. Więc wymyślono coś takiego jak travelsat_nat w ipsec. Jest to wszystko niby dopracowane ale nie zawsze działa. Zbawieniem będzie tutaj ipv6 bo tam nie będzie wreszcie takich problemów.
Zresztą co ja będę się rozpisywał widzę że lepiej wiecie...

Najlepiej to obaj dajcie logi z

iptables -L -v
iptables -t nat -L -v

do tej pory nic nie pokazaliście mimo że wcześniej prosiłem. Jak wina firewalla to tam będzie to widać pod razu.

bez tego ciężko zobaczyć gdzie są błędy

@lukaszp
ja domyślnie swoje reguły dodałem do reguł postrouting_rule i forwarding_rule. Uważam że to bardziej elegancki sposób na dodawanie reguł jak prosto do łańcuchów głównych
mogło się zdarzyć że developerzy coś pozmieniali w kolejności ładowania poszczególnych reguł. OpenWrt ciągle ewaluuje
Więc błędem nie będzie jak lekko przerobisz swoje reguły i zamienisz poszczególne słowa
postrouting_rule -> POSTROUTING
forwarding_rule -> FORWARD
czyli

iptables -I FORWARD --src 172.20.35.0/27 -j ACCEPT
iptables -I FORWARD --dst 172.20.35.0/27 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.223.0/27 -d 172.20.35.0/27 -j ACCEPT
iptables -t nat -I POSTROUTING -p ipcomp -j ACCEPT
iptables -t nat -I POSTROUTING -p ah -j ACCEPT
iptables -t nat -I POSTROUTING -p esp -j ACCEPT

jeśli to wina firewalla to powinna ta zmiana rozwiązać sytuację

jeszcze w prosty sposób wyjaśnię wpisy w setkey.conf na przykładzie lukaszp

spdadd 192.168.223.0/27 172.20.35.0/27 any -P out ipsec
esp/tunnel/83.220.*.58-217.97.*.174/require;

Powyższy wpis oznacza:
jeśli pakiety idą z sieci 192.168.223.0/27 i jednocześnie idą do sieci 172.20.35.0/27 to są to pakiety wychodzące OUT z naszego routera. VPN zestawiony poprzez adresy końcowe (83.220.*.58-217.97.*.174). Typ VPN to tunnel

spdadd 172.20.35.0/27 192.168.223.0/27 any -P in ipsec
esp/tunnel/217.97.*.174-83.220.*.58/require;

jeśli pakiety idą z sieci 172.20.35.0/27 i jednocześnie ią do sieci 192.168.223.0/27 to są to pakiety przychodzące IN do naszego routera. VPN zestawiony poprzez adresy końcowe (217.97.*.174-83.220.*.58). Typ VPN to tunnel

@roland
u ciebie podobnie

iptables -I  FORWARD --src 192.168.11.0/24 -j ACCEPT
iptables -I FORWARD --dst 192.168.11.0/24 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.11.0/24 -j ACCEPT
iptables -t nat -I POSTROUTING -p ipcomp -j ACCEPT
iptables -t nat -I POSTROUTING -p ah -j ACCEPT
iptables -t nat -I POSTROUTING -p esp -j ACCEPT

Wyjaśnię jeszcze sprawę opcji "generate policies"
Używa się jej tylko do wygenerowania reguł. Jeśli są one poprawnie zdefiniowane po obu stronach nie ma potrzeby używać tej opcji. Nie wiesz jak naprawdę dlink rozwiązał opcję generacji tych reguł. Nie wiesz nawet czy na swoim pokładzie ma racoon. Równie dobrze może mieć openswana(on inaczej troszkę działa) lub inne rozwiązanie
Może być tak (tak widziadłem w jednym z routerów) że nie chce im się pisać skryptów generujących wpisy w setkey.conf i po prostu włączają tą opcję na on a resztą zajmuje się opcja generowania. Ale to nie jest elegancki sposób na to.

@roland
te logi ... coś mi pachnie przechodzeniem pakietów przez POSTROUTING a tu generalnie powinno omijać się NAT
sprawdź czy router obsługuje nat_traversal jeśli tak załącz go bo coś mi się widzi że pakiety u twojego dostawcy idą przez POSTROUTING. Owszem zrobił przekierowanie ale pakiety NIE MOGĄ przechodzić przez POSTROUTING bo są modyfikowane i dlatego się wykszacza

jak router obsługuje nat_traversal to trzeba go tylko w pliku configuracyjnym załączyć i powinno być ok nawet bez przekierowań
pokaż swojego firewalla

@lukaszp
nie wiem czy masz miejsce ale jak możesz zainstaluj sobie zamiast tcpdump-mini pełne tcpdump
i wtedy

tcpdump -i 3g-wan icmp

będzie działał

interesuje mnie czy przychodzą pakiety z powrotem

Generalnie u Ciebie bez analizy dokładnej logów racoon i pakietów nie wiesz czy problem jest u Ciebie czy u Kolegi

Można jeszcze wspomóc się poniższymi wierszami

racoon -F -f /etc/racoon/racoon.conf
racoon -F -v -f /etc/racoon/racoon.conf

najpierw wyłącz racoon tak aby nie pracował
a potem odpal pierwszy z wierszy (to drugie to daje o wiele potężniejszy log)
nie wyłączając konsoli wykonaj coś na komputerze wewnątrz lan
wklej zawartość tutaj oczywiści pingnij drugą stronę aby tunel się zestawił zupełnie

daj jeszcze loga z

iptables -t nat -L -v
iptables -L -v

zdecyduj się jakie masz maski bo raz piszesz /27 a raz /24

z czego wynika maska /27. Masz tylko 30 użyteczne adresy+siec i brodcast ?
Czyli jak rozumiem masz siec co ma maksymalnie 30 hostów. Ale kombinujesz

co to za dlink ? można jakieś zrzuty tego dlinka ?

przestaw opcje na

generate_policy off;

i pokaż logi z racoon z debug

tym w DP się nie przejmuj tak jest ok. Najważniejsze że widać że masz zestawione in,out,fw

co do pingowania w jedną strone stawiałbym na firewalla
tutaj pomoże tylko tcpdump-mini na routerku

tcpdump icmp

pingnij z jednej sieci lan do drugiej i pokaż wynik

ew. na chwilkę wydaj z konsoli komendę

iptables -I FORWARD -j ACCEPT

i zobacz czy ping odpowiada

a jak już można podać logi z firewalla

iptables -t nat -L -v
iptables -L -v

@lukaszp
zdefiniuj wpisy w pliku setkey.conf albo pokaż tu jego zawartość bo się pluje. (wpisy policy)

jak rozumiem po twojej stronie jest racoon a po drugiej stronie co stoi ? openwrt z racoon, router sprzętowy z ipsec ?
możliwości może być wiele
jeśli z drugiej strony stoi racoon to szukałbym na początek problemu w firewallu lub postroutingu
jeśli jest to router sprzętowy to no cóż nie każdy umożliwia dostanie się do portu LAN routera na którym stoi ipsec. Pingnij jakiś host w odległej sieci LAN nie router i zobacz wtedy

wspomóż się iptraf/Wireshark/tcpdump. Zobacz jak ida pakiety czy sa pakiety icmp echo/request.

@roland
z tym poradzeniem z natem to bym polemizował
musisz mieć pewne przekierowanie portów niekoniecznie 500 ale musi być. Poza tym jeśli twój dostawca przepuścił konfigurację przez POSTROUTING może nie być komunikacji.
Jeśli chodzi o traversal NAT to jeśli ty masz adres z lan a druga strona ma adres publiczny powinieneś byc stroną inicjującą połaczenie
odpuść sobie plik etc/racoon/backupsa.txt w konfiguracji chyba że masz zapasowy serwer ipsec

policy jak wyżej w pliku setkey.conf się znajduje

masz załadowane moduły pf i af ?

Generalnie od obu poproszę pełne konfigi bo to wróżenie z fusów. Do tego jeszcze mały opis z czym się łączycie. jeśli to linux to config z drugiej strony
do tego na poczatek

lsmod
setkey -D
setkey -DP

no nie aż sprawdziłem i nie wiem jak u ciebie ale u mnie działa
proszę bardzo
na komputerze z linuxem ustawiłem dwa vlan 100 i 200
na openwrt w wr1043nd włączyłem tcpdump-mini z opcjami

tcpdump -n -e -vv -ttt -i wlan0 vlan

wynikiem zwykłego pingu z laptopa jest log z openwrt

root@OpenWrt:~# tcpdump -n -e -vv -ttt -i wlan0 vlan
tcpdump: WARNING: wlan0: no IPv4 address assigned
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
00:00:00.000000 00:1c:bf:9f:d7:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.1 tell 10.0.0.10, length 28
00:00:00.000079 00:1c:bf:9f:d7:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.1 tell 10.0.0.10, length 28
root@OpenWrt:~# tcpdump -n -e -vv -ttt -i wlan0 vlan
tcpdump: WARNING: wlan0: no IPv4 address assigned
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
00:00:00.000000 00:1c:bf:9f:d7:60 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 200, p 0, ethertype IPv6, (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6, multicast listener report v2, length 28, 1 group record(s)[|icmp6]
00:00:00.000080 00:1c:bf:9f:d7:60 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 200, p 0, ethertype IPv6, (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6, multicast listener report v2, length 28, 1 group record(s)[|icmp6]
00:00:00.000109 00:1c:bf:9f:d7:60 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 200, p 0, ethertype IPv4, (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))

więc jak widzisz da się i to działa

@roland nie załadowane moduły od ipsec - pewnie brak
@lukaszp z tego co pamiętam to w backfire nie musiałem go instalować bo go nie było ale działało na pewno

całkiem logiczne. Da się coś takiego zrobić.
Z gotowych pakietów poszukaj np. multiwan
albo można ręcznie to zrobić poprzez ip route/ip rule + ew iptables
http://bromirski.net/docs/translations/lartc-pl.html

słaba wydajnosc pradowa usb ?
zmień tryb bulk/iso usb jak sie da

tcpdump - zmień interfejs z eth0 na br-lan
ta komenda to na końcu do sprawdzenia pakietów.

a wracając do iptables i route wydaj komendy z ręki po prostu to sie nic nie zapamieta

ip route add 244.0.0.0/4 dev eth0.6

iptables -I INPUT -p igmp -j ACCEPT
iptables -I FORWARD -i eth0.6 -p udp -j ACCEPT
iptables -I INPUT -i eth0.6 -d 239.2.0.0/16 -j ACCEPT

iptables -t filter -I INPUT -d 239.0.0.0/240.0.0.0 -i eth0.6 -j ACCEPT
iptables -t filter -I INPUT -s 239.0.0.0/240.0.0.0 -i eth0.6 -j ACCEPT
iptables -t filter -I FORWARD -d 239.0.0.0/240.0.0.0 -j ACCEPT
iptables -t filter -I FORWARD -s 239.0.0.0/240.0.0.0 -j ACCEPT
iptables -t mangle -I PREROUTING -d 239.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1
iptables -t nat -I POSTROUTING -o eth0.6 -j MASQUERADE

potem uruchom igmpproxy z w/podaną konfiguracją

/etc/init.d/igmpproxy start

i zobacz

ale tak jak pisałem nie wiem czy to ok jest w ogóle.

ps.nie wiem czy masz zainstalowany modul ipt_TTL ale to sie okaze w czasie wpisywania powyższych wierszy

w razie czego można skorzystać w igmpproxy z trybu debug

igmpproxy -d -v /etc/igmpproxy.conf

zainstaluj ip czyli

opkg update
opkg install ip

i masz komendy ip
i daj wreszcie log z

ip route

z racji tego że nie miałem z iptv nic do czynienia to musisz sam ustawić firewall i igmpproxy
może inny forumowicz będzie wiedział więcej na ten temat

to wszystko co napiszę to tylko domysły i internet więc nie wiem czy w ogóle będzie działać

iptables -I INPUT -p igmp -j ACCEPT
iptables -I FORWARD -i eth0.6 -p udp -j ACCEPT
iptables -I INPUT -i eth0.6 -d 239.2.0.0/16 -j ACCEPT

insmod ipt_TTL
iptables -t filter -I INPUT -d 239.0.0.0/240.0.0.0 -i eth0.6 -j ACCEPT
iptables -t filter -I INPUT -s 239.0.0.0/240.0.0.0 -i eth0.6 -j ACCEPT
iptables -t filter -I FORWARD -d 239.0.0.0/240.0.0.0 -j ACCEPT
iptables -t filter -I FORWARD -s 239.0.0.0/240.0.0.0 -j ACCEPT
iptables -t mangle -I PREROUTING -d 239.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1
iptables -t nat -I POSTROUTING -o eth0.6 -j MASQUERADE

co do igmpproxy to myślę że może wyglądać następująco:

quickleave
phyint eth0.6 upstream ratelimit 0 threshold 1
altnet 239.0.0.0/8
phyint br-lan downstream ratelimit 0 threshold 1
phyint eth0.5 disabled
phyint eth0.1 disabled

ja bym jeszcze trase dodał

ip route add 244.0.0.0/4 dev eth0.6

to jak idą pakiety możesz podejrzeć

tcpdump -vvv -ni eth0 igmp

no jak dostaje adres ip vlan6 no może vlan5 to zostaw te zmiany które przydzielają routerowi adresy
Wtedy będziemy mieć pełniejszy obraz sytuacji jaka jest od strony dostawcy.
Oczywiście pełne logi tutaj proszę wkleić

zainstaluj sobie na openwrt igmpproxy

opkg update
opkg install igmpproxy

może się przydać