tak
tak
niezupełnie. czytałeś w ogóle o EUI-64 ? dhcpv6 nie nada adresu ip po MAC i kropka. Z adresów EUI-64 minnymi korzysta radvd a w zasadzie jego klienci. Tutaj zarządzasz za pomocą DUID.
nie sa potrzebne te pakiety

do swoich potrzeb musisz wymyślić sobie jakiś prefix aby to zadziałało sensownie

resztę musisz doczytać sobie sam. przede wszystkim o podstawach w ipv6 przydała by się jakaś wiedza. Na tacy to raczej nikt nie będzie podawał pełnego rozwiązania

ee coś by się tam znalazło typu compatible ipv6 jakby dobrze poszukać

lukaszp: jabber

no fakt nie zauważyłem. Trochę to mylące. Nowy temat byłby lepszy a tak muli

ale do rzeczy

nie znam tego sprzętu ale ja bym zaczął od czegoś takiego

config interface loopback
        option ifname   lo
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

config interface lan
        option ifname   eth0.1
        option type     bridge
        option proto    static
        option ipaddr   10.0.0.1
        option netmask  255.255.255.0

config interface wan
        option ifname   eth1
        option proto    dhcp

config  'interface' 'vlan2'
        option 'ifname' 'eth0.2'
        option 'proto' 'static'
        option 'ipaddr' '192.168.1.2'
        option 'netmask' '255.255.255.0'

config switch
        option name     rtl8366s
        option reset    1
        option enable_vlan 1

config switch_vlan
        option device   rtl8366s
        option vlan     1
        option ports    "0 1 2 5t"

config switch_vlan
        option device   rtl8366s
        option vlan     2
        option ports    "3 5t"

gdzie porty z tego co widzę na necie są przypisane następująco:

0 -> Physical port tag 4
1 -> Physical port tag 3
2 -> Physical port tag 2
3 -> Physical port tag 1
4 -> Physical port tag Internet (eth1)
5 -> Internal connected to the CPU (eth0)

port 4 is NOT connected to the switch and shall not be used with swconfig, use regular vconfig to add Q tags to it

prawidłowe przypisanie portów i vlan sprawdzisz sobie komendami

swconfig dev rtl8366s vlan 1 show
swconfig dev rtl8366s vlan 2 show

to dopisz bo to nie ma sensu. Na 5 musi byc trunk inaczej jaki miało by to sens ?

zmień do testu  w sainfo na

sainfo anonymous {
........................................
        lifetime time 60 sec;
............................................
}

i zobacz co się będzie działo ?

szkoda że nie masz możliwości dostania logów z cisco
show debug
z połączenia
tam by były przydatne informacje (szukać po RESPONDER-LIFETIME")

to ja jeszcze poprosze

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

tak jak wyżej z nawiązania połaczenia

dziwne jeśli to co dałeś w logu jest ok to postrouting_rule winien załatwić bezproblemowo sprawę bo jest przed nat i nie jest przypisany do iface
tam przenieśli nat_reflection może on zaburza całą sprawę
trzeba by sprawdzić czy reguły dodają się przed nat reflection w postrouting_rule
u mnie sprawdziłem regułki dodają się przed nat_reflection wiec mimo wszystko powinno być ok w łańcuchu postrouting_rule

jeśli możesz pokaż log ze swojego routera

/etc/init.d/racoon stop
racoon -F -f /etc/racoon/racoon.conf 

pingnij z lan siec odległą aby wszystko się zestawiło
i wklej tu log
i pokaż jeszcze raz plik z konfiguracją /etc/racoon/racoon.conf

jeszcze jedno
to wycinek twojego logu

192.168.223.0/27[any] 172.20.35.0/27[any] any
        out prio def ipsec
        esp/tunnel/83.220.8.58-217.97.*.174/require
        created: Feb  9 08:01:41 2011  lastused: Feb  9 08:03:50 2011
        lifetime: 3600(s) validtime: 0(s)
        spid=625 seq=1 pid=16275
        refcnt=3

zerknij na lifetime i masz swoją godzinę

natt_keepalive ci sie nie przyda bo jest od nat traversal
czy na pewno masz ustawione po obu stronach identyczne lifetime ?
lifetime powinno być w phase1 i phase2 takie same dla obu stron połączeń

no bo masz zdublowane reguły to po pierwsze - widać w POSTROUTING

Chain POSTROUTING (policy ACCEPT 11 packets, 780 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1   136 ACCEPT     esp  --  any    any     anywhere             anywhere
    0     0 ACCEPT     ah   --  any    any     anywhere             anywhere
    0     0 ACCEPT     ipcomp--  any    any     anywhere             anywhere
    2   168 ACCEPT     all  --  any    any     172.16.200.240/28    150.2.*.0/16
    0     0 ACCEPT     esp  --  any    any     anywhere             anywhere
    0     0 ACCEPT     ah   --  any    any     anywhere             anywhere
    0     0 ACCEPT     ipcomp--  any    any     anywhere             anywhere
    0     0 ACCEPT     all  --  any    any     172.16.200.240/28    150.2.*.0/16
   76  5528 postrouting_rule  all  --  any    any     anywhere             anywhere
   37  2800 zone_wan_nat  all  --  any    3g-wan  anywhere             anywhere

przepisz z powrotem reguły firewalla (iptables) z /etc/init.d/racoon do /etc/firewall.user tak jak było w oryginale i przeładuj najpierw firewalla a potem racoon

dlaczego racoon a nie openswan ?
bo mało opisywany
bo mniej popularny
bo mi pasi

tak po prawdzie kiedyś miałem freeswan (2.2/2.4) i się przejechałem . Musiałem się na coś zdecydować więc przeszedłem na racoon tak jakoś łatwo się zrobiło i działa po dziś dzień na debianie bez problemu już z 10 lat.

ja wiem czy lepszy czy gorszy. W sumie to robi ten sam efekt tylko innymi narzędziami
w sumie to tak naprawdę w racoon też jest łatwa konfiguracja ale ja z niej nigdy nie korzystałem bo nie musiałem

Dla usera to openswan jest czytelniejszy bo masz rzeczywisty interfejs np. ipsec0 do którego możesz podczepiać reguły firewalla. Lepiej to widać
A racoon działa na poziomie jądra więc w sumie uogólniając wszystko dzieje się jakoś przezroczyście. Pakiety są przechwytywane w locie i są wysyłane tam gdzie należy. W openswan widzisz że jak wyślesz na ipsec0 to pakiety idą tamtędy a tu nie jest to takie oczywiste na pierwszy rzut oka

Tak naprawdę racoon działa a to że coś się zmienia w openwrt to trzeba się do tego przyzwyczaić. Trzy razy coś developerzy poprawią a raz zepsują. Normalna rzecz a ja pewnie jeszcze wiele razy zanim zauważę że coś zmienili będę modyfikował wersje arta pod openwrt

1)to że tunel się zestawia miedzy hostami w lan automatycznie to normalne. Sam tunel między gateway na których stoi ipsec się nie zestawi całkowicie chyba że wywołasz ręcznie komendę connect w cli racoon

  racoonctl vpn-connect [-u identity] vpn_gateway
  racoonctl vpn-disconnect vpn_gateway

2)Bardzo często nie da się z routera który jest gatewayem vpn dostać na drugą stronę. Wynika to z różnych przyczyn. Jedną z nich jest adres źródłowy. Tunel musi dostać pakiet z lan a pingując standardowo z routera drugą stronę adresem źródłowym niekoniecznie jest adres ip interfejsu lan i to jest rónież przyczyną niemożności dostania się z routera po vpn na drógą stronę. Co do ping można w pewien sposób poradzić sobie z tym podając opcję -I IP_ADRES_IFACE_LAN

3)Nie moja wina że developerzy openwrt ciągle coś przerabiają w firewallu(nawet to dobrze że firewall ciągle ewoluuje). Ale w tym wypadku mocno przegięli.  Dla mnie to oczywisty błąd bo reguły z /etc/firewall.user powinny mieć pierwszeństwo nad tymi co są ładowane ze skryptów (/etc/config/firewall). Znaczy się powinny być ładowane na końcu. Niestety developerzy postarali się o to że przestawili reguły NAT dotyczące WAN i LAN na początek reguł POSTROUTING i za chiny ludowe nie da się czegokolwiek wstawić przed nimi z pliku /etc/firewall.user
Poprzednio Reguły NAT z WAN i LAN były za łańcuchem postouting_rule teraz niestety są przed. Więc użytkownikowi nie pozostawia się ŻADNEGO pola działania.
Mocno zastanawiam się czy modyfikować mój opis. Zmiany które wprowadzili są dla mnie dość kontrowersyjne. Nie wiem może na końcu każdego dokumentów napiszę o tym aby inni wiedzieli że coś nie tak.

Dlatego przeniesienie reguł dotyczących ipsec do własnego skryptu uruchamianego po firewallu jest wręcz wymagane.

potwierdzeniem tego co pisze wyżej jest ustawienie kolejności reguł

Chain POSTROUTING (policy ACCEPT 246 packets, 18433 bytes)
 pkts bytes target     prot opt in     out     source               destination
  854 61486 zone_wan_nat  all  --  any    eth0.2  anywhere             anywhere
    1    84 zone_lan_nat  all  --  any    br-lan  anywhere             anywhere
    0     0 ACCEPT     esp  --  any    any     anywhere             anywhere
    0     0 ACCEPT     ah   --  any    any     anywhere             anywhere
    0     0 ACCEPT     ipcomp--  any    any     anywhere             anywhere
    0     0 ACCEPT     all  --  any    any     192.168.1.0/24       192.168.11.0/24
  246 18433 postrouting_rule  all  --  any    any     anywhere             anywhere

nasze reguły zostały wstawione za NAT .
Zwracam uwagę że nie mogę użyć łańcuchów
zone_wan_nat i zone_lan_nat
ponieważ są one powiązane jasno z interfejsem fizycznym
W przypadku racoon nie ma czegoś takiego jak fizyczny interfejs

Można oczywiście użyć openswan on już ma iface np. ipsec0

PS. przerobiłem arta.

wpisz te reguły do pliku

/etc/rc.local

zamiast do /etc/firewall.user

tak na początek
to powinno odpowiednio wstawić reguły

wadą rozwiązania jest to że nie przeładujesz reguł firewalla poprawnie bo zmiany nie będą uwzględniane

inną możliwością jest napisanie własnego skryptu w stylu

touch /etc/init.d/racoon
chmod +x /etc/init.d/racoon

o zawartości:

#!/bin/sh /etc/rc.common

START=98

start() {
echo Laduje reguly iptables dla ipsec
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

echo Uruchamiam tunel ipsec racoon...

if [ ! -e /var/racoon ]
then
mkdir /var/racoon
fi
setkey -f /etc/racoon/setkey.conf
racoon -f /etc/racoon/racoon.conf

}

stop() {
iptables -D FORWARD --src 192.168.11.0/24 -j ACCEPT
iptables -D FORWARD --dst 192.168.11.0/24 -j ACCEPT
iptables -t nat -D POSTROUTING -s 192.168.1.0/24 -d 192.168.11.0/24 -j ACCEPT
iptables -t nat -D POSTROUTING -p ipcomp -j ACCEPT
iptables -t nat -D POSTROUTING -p ah -j ACCEPT
iptables -t nat -D POSTROUTING -p esp -j ACCEPT

killall racoon
}

potem

/etc/init.d/racoon enable
/etc/init.d/racoon start

jak widzisz trochę przerobiłem skrypt uruchamiający racoon i przeniosłem reguły firewalla dotyczące ipsec
teraz reguły winny znaleźć się tam gdzie trzeba
teraz po restarcie firewalla powinieneś zrestartować racoon i powinno być git

co do przesłania pakietów
w takim układzie źle są składane reguły w setkey.conf albo po stronie racoon albo po stronie netgeara. To one decydują o tym jak kierowane są pakiety
Trzeba by było obejrzeć szczegółowe logi z połączeń te bardzo szczegółowe