| Thema |
Verfasser |
Letzte Antwort |
| Openwrt/Openswan - Openwrt/Openswan |
chrisidc ( ---.162.66.68) |
17 Dec 2009 18:29 |
Hallo,
ich habe ein Problem das der Tunnel zwar ab ist, aber ein ping ins andere Netz nicht funktioniert (ipsec0 interface dropped die Packete).
Ich habe folgendes Testnetz:
ClientNet1 - 192.168.1.1/24 OPENWRT1(WRT54Gv2.2) 10.0.1.1/24 --- 10.0.1.254/24 Router 10.0.2.254/24 Router --- 10.0.2.1/24 OPENWRT2(WRT54GLv1.1) 192.168.2.1/24 - ClientNet2
config-files (auf beiden Seiten gleich):
root@openwrt2:/etc# more ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
plutodebug="none"
klipsdebug="none"
nat_traversal=no
interfaces=%defaultroute
# Add connections here
conn TestVPN
type = tunnel
left = 10.0.2.1
leftsubnet = 192.168.2.0/255.255.255.0
leftnexthop=10.0.2.254
leftsourceip=192.168.2.1
right = 10.0.1.1
rightsubnet = 192.168.1.0/255.255.255.0
rightnexthop=10.0.1.254
keyexchange = ike
auth = esp
authby = secret
pfs = yes
ikelifetime = 5h
rekeyfuzz = 50%
rekeymargin = 10s
dpddelay = 5
dpdtimeout = 15
dpdaction=restart
auto = start
keyingtries = %forever
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
root@openwrt2:/etc# more ipsec.secrets
# PSK for tunnel from specific ip to specific ip
#192.168.3.2 192.168.3.1: PSK "abc123"
# PSK for tunnel from any ip to any ip
: PSK "meinpassword"
Tunnel steht:
root@openwrt1:/etc# ipsec auto --status
...
000 #5: "TestVPN":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 28486s; newest IPSEC; eroute owner
000 #5: "TestVPN" esp.b3b536f1@10.0.2.1 esp.85669310@10.0.1.1 tun.1006@10.0.2.1 tun.1005@10.0.1.1
000 #4: "TestVPN":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 28485s
000 #4: "TestVPN" esp.b3b536f0@10.0.2.1 esp.8566930f@10.0.1.1 tun.1004@10.0.2.1 tun.1003@10.0.1.1
000 #1: "TestVPN":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 17686s; newest ISAKMP; lastdpd=2s(seq in:0 out:0)
000 #3: "TestVPN":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28488s
000 #3: "TestVPN" esp.b3b536ef@10.0.2.1 esp.8566930e@10.0.1.1 tun.1002@10.0.2.1 tun.1001@10.0.1.1
000 #2: "TestVPN":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 17687s; lastdpd=2s(seq in:23127 out:0)
000
Die Packete werden vom ipsec0 interface entweder als error oder dropped angezeigt:
root@openwrt1:/etc# ifconfig ipsec0
ipsec0 Link encap:Ethernet HWaddr 00:18:F8:51:0C:B3
inet addr:10.0.1.1 Mask:255.255.255.0
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:1 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@openwrt2:/etc# ifconfig ipsec0
ipsec0 Link encap:Ethernet HWaddr 00:12:17 D:BB:02
inet addr:10.0.2.1 Mask:255.255.255.0
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:49 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
routing table:
root@openwrt1:/etc# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.2.0 10.0.1.254 255.255.255.0 UG 0 0 0 ipsec0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 10.0.1.254 0.0.0.0 UG 0 0 0 vlan1
root@openwrt2:/etc# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.1.0 10.0.2.254 255.255.255.0 UG 0 0 0 ipsec0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
0.0.0.0 10.0.2.254 0.0.0.0 UG 0 0 0 vlan1
Aber ich bekomme keine Antwort auf meine Pings wenn ich von einem Client einen anderen Client pinge.
Wenn ich ipsec ausschalte funktioniert der ping (Router hat auch Routingeinträge für die Netz - obwohl er die ja beim Tunnel nicht brauchen würde).
Interessant ist noch das der Tunnel inklusive ping funktioniert wenn die beiden Openwrt im gleichen Subnetz hängen.
Wäre toll wenn mir jemand helfen könnte?
Vielen Dank
Chris
|
| ||
| RE: Openwrt/Openswan - Openwrt/Openswan | Ralf ( ---.dip.t-dialin.net) | 7 Dec 2009 16:45 |
Hallo,
Du pingst also von Client zu Client und nicht von OpenWRT zu OpenWRT?
Gibt es Firewall oder NAT-Regeln?
Was siehst Du mit tcpdump auf den Routern?
Gruß,
Ralf |
| RE: RE: Openwrt/Openswan - Openwrt/Openswan | chrisidc ( ---.public.t-mobile.at) | 7 Dec 2009 17:36 |
Danke für die schnelle Rückmeldung.
Also eigentlich pinge ich von einem wirklichen Client (192.168.1.142) das LAN Interface vom anderen Router (192.168.2.1).
Es funktioniert aber auch nicht wenn ich folgendes von den openwrt's LAN 2 LAN pinge.
"ping 192.168.2.1 -I 192.168.1.1"
bzw. vom anderen
"ping 192.168.1.1 -I 192.168.2.1
Firewall ist überall ausgeschalten bzw. auf ACCEPT ALL gesetzt.
root@openwrt1:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
tcpdump habe ich nicht verwendet, weil er mir dann immer die SSH Packete im Fenster "zurückschleift" und das etwas unübersichtlich ist.
Deshalb habe ich zwischen openwrt1 und dem Router mittels Whireshark gesnifft. Ich sehe nur ISAKMP Packete, aber keine ESP Packete. Diese ISAKMP Packete sind auch nur Info-Nachrichten. Wenn ich ipsec auf beiden Seiten stoppe sehe ich den ping (icmp echo request und reply) in beide Richtungen.
==> Der openwrt1 schickt die Packete gar nicht (zum Router weiter, sondern dropped sie am ipsec0 interface.
Wenn ich den Router weglasse (also die openwrt's im gleichen Subnetz habe) sehe ich beim sniffen auch die ESP Packete.
Könnte es sein das irgendetwas mit dem left/right-nexthop oder left/right-sourceip falsch ist?
|
| RE: RE: RE: Openwrt/Openswan - Openwrt/Openswan | Ralf ( ---.dip.t-dialin.net) | 8 Dec 2009 06:11 |
Hallo,
Dann sollte es eigentlich funktionieren. Sind NAT-Regeln auf dem OpenWRT oder Router aktiv?
Gruß,
Ralf
|
| RE: RE: RE: RE: Openwrt/Openswan - Openwrt/Openswan | chrisidc ( ---.23.11.vie.surfer.at) | 8 Dec 2009 21:29 |
Hallo Ralf,
also NAT ist nicht im Spiel.
Mittlerweile habe ich das Problem aber auch schon wenn die Openwrts im gleichen Subnet (also ohne Router) hängen, obwohl diese Teststellung schon funktioniert hat.
Was mir in diesem Falls komisch vorkommt, dass die Routingtabelle für die LAN-Netze 2 Einträge hat und zwar einmal über das ipsec0 und einmal über das normale Interface.
Könnte das ein Problem sein? Wenn ich den normalen Eintrag händisch gelöscht habe, hat es aber auch nicht funktioniert.
Das komische ist, dass der Tunnel als up angezeigt wird. Ich sehe aber mit tcpdump regelmäßig Phase2 Kommunikation zwischen den Gateways. Aber keine ESP Packete. Und komischerweise konnte in von einem Openwrt die WAN Seite des anderen pingen, aber umgekehrt hat es nicht funktionert.
Also ziemlich komisches Problem.
Vielleicht gibt es aber auch einen Bug bei der verwendeten Software.
Ich verwende im Moment:
Openwrt Whiterussion RC6
kmod-openswan - 2.4.30brcm+2.4.6-2 - Openswan IPSec kernel module
openswan - 2.4.6-1 - Openswan IPSec software
Ich werde mal versuchen auf andere Versionen zu wechseln (bei der neuesten Whiterussion wurde allerdings nicht mal der Tunnel aufgebaut).
Grüße
Chris
|
| RE: RE: RE: RE: RE: Openwrt/Openswan - Openwrt/Openswan | Ralf ( ---.dip.t-dialin.net) | 10 Dec 2009 07:31 |
Bestätigen denn beide OpenWRT, dass der Tunnel steht?
Gruß,
Ralf |
| RE: RE: RE: RE: RE: RE: Openwrt/Openswan - Openwrt/Openswan | chrisidc ( ---.162.66.68) | 10 Dec 2009 08:23 |
> Bestätigen denn beide OpenWRT, dass der Tunnel steht?
Ja, auf beiden Seiten sehe ich established.
Nur droppen dann beide auf dem ipsec0 interface die Packete, wenn sie z.B. einen ping weiterschicken sollten.
Deshalb sehe ich auch nie irgendwelche selbst generierte Packete auf den WAN-Interfaces der Router rausgehen.
|
| RE: RE: RE: RE: RE: RE: RE: Openwrt/Openswan - Openwrt/Opens... | Ralf ( ---.dip.t-dialin.net) | 11 Dec 2009 06:54 |
Beide Seiten melden auch die Phase 2 als established?
Ist rp_filter aktiv?
Wenn keine Firewall und keinerlei NAT ansonsten aktiv ist, weiss ich ohne Zugriff nicht weiter :-(
Gruß,
Ralf |
| RE: RE: RE: RE: RE: RE: RE: RE: Openwrt/Openswan - Openwrt/O... | chrisidc ( ---.adsl.highway.telekom.at) | 13 Dec 2009 19:24 |
rp_filter=0 in den entsprechenden files
Also mir kommt es so vor als wäre das ganze ziemlich instabil (obwohl in den logfiles immer alles Ok aussieht).
Ich bin jetzt wenigsten soweit das die Lösung im direkten Netz wieder funktioniert.
Dazu musste ich aber openswan auf beiden Seiten 3-4 mal restarten (obwohl bei "ipsec auto --status" und "logread" alles OK aussah, funktionierte kein ping).
Wie sieht die Lösung jetzt aus (falls mal wer das gleiche machen will):
Testnetz:
192.168.1.1/24 (LAN) openwrt1 (WAN) 192.168.0.1/24 <===> 192.168.0.2/24 (WAN) openwrt2 (LAN) 192.168.2.1/24
#########################################
root@openwrt1:~# more /etc/ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
plutodebug="none"
klipsdebug="none"
nat_traversal=no
interfaces=%defaultroute
# Add connections here
conn TestVPN
authby=secret
keyexchange=ike
ikelifetime=480m
keylife=60m
pfs=yes
left=192.168.0.2
leftsubnet=192.168.2.0/24
leftnexthop=%defaultroute
right=192.168.0.1
rightsubnet=192.168.1.0/24
rightnexthop=%defaultroute
auto=start
leftsourceip=192.168.2.1
rightsourceip=192.168.1.1
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
#########################################
tcpdump zeigt:
00:22:34.293431 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x604ca633,seq=0x45), length 132
00:22:35.291252 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x92a91965,seq=0x46), length 132
00:22:35.293437 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x604ca633,seq=0x46), length 132
logread:
...
Jan 1 00:21:39 (none) kern.warn pluto[4032]: "TestVPN" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Jan 1 00:21:39 (none) kern.warn pluto[4032]: "TestVPN" #4: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
Jan 1 00:21:40 (none) kern.warn pluto[4032]: "TestVPN" #4: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Jan 1 00:21:40 (none) kern.warn pluto[4032]: "TestVPN" #4: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x604ca633 <0x92a91965 xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
ipsec auto --status
...
000 #3: "TestVPN":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3153s
000 #3: "TestVPN" esp.604ca632@192.168.0.2 esp.92a91964@192.168.0.1 tun.1002@192.168.0.2 tun.1001@192.168.0.1
000 #2: "TestVPN":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 28352s; lastdpd=-1s(seq in:0 out:0)
000
#########################################
Aber die pings funktionieren einmal und einmal nicht.
Mir ist jetzt etwas in den Routing Tabellen aufgefallen:
root@openwrt1:~# ip route
192.168.2.0/24 dev ipsec0 scope link src 192.168.1.1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.0.0/24 dev vlan1 proto kernel scope link src 192.168.0.1
192.168.0.0/24 dev ipsec0 proto kernel scope link src 192.168.0.1
default via 192.168.0.2 dev vlan1
root@openwrt1:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
0.0.0.0 192.168.0.2 0.0.0.0 UG 0 0 0 vlan1
root@openwrt2:~# ip route
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1
192.168.1.0/24 dev ipsec0 scope link src 192.168.2.1
192.168.0.0/24 dev vlan1 proto kernel scope link src 192.168.0.2
192.168.0.0/24 dev ipsec0 proto kernel scope link src 192.168.0.2
default via 192.168.0.1 dev vlan1
root@openwrt2:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 vlan1
###########
Mir kommt der Teil:
root@openwrt1:~# ip route
192.168.2.0/24 dev ipsec0 scope link src 192.168.1.1
root@openwrt2:~# ip route
192.168.1.0/24 dev ipsec0 scope link src 192.168.2.1
etwas komisch vor.
Liegt das an left/right sourceip?
Darf man die nicht gleichzeitig verwenden?
Ich hatte jetzt komische Probleme, wenn ich gleichzeitig von beiden Seiten pinge funktioniert der ping und wenn ich den ping auf einer Seite stoppe, funktioniert der ping von der anderen Seite auch nicht mehr.
Später hatte ich dann das Problem, wenn ich von einer Seite pinge funktionioniert der ping von der anderen Seite nicht bis ich die andere Seite stoppe.
Also das wird immer lustiger.
Vielen Dank
Grüße
Christoph
PS: Werde die config mit dem Router dazwischen auch nochmals testen.
PPS: Ab wann gibts die neue Version des Buches "VPN mit Linux" eigentlich zu kaufen und wird da statt freeswan dann open/strong swan erklärt?
|
| RE: RE: RE: RE: RE: RE: RE: RE: RE: Openwrt/Openswan - Openw... | Ralf ( ---.117.215.234) | 16 Dec 2009 07:36 |
Das mit der src-Adresse stimmt, denke ich.
Was mich im Moment mehr wundert, ist dass das Netz 192.168.0.0 zwei Routen (über vlan1 und ipsec0) besitzt.
Ich habe aber im Moment kein altes System mit ipsec0-Interfaces mehr zum testen.
Das neue Buch wird in wenigen Monaten rauskommen. Allerdings verzichtet es komplett auf ipsec0-Konfigurationen, da diese heute nur noch sehr selten sind (Kernel 2.4).
Gruß,
Ralf |
| RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: Openwrt/Openswan - O... | Ralf ( ---.117.215.234) | 16 Dec 2009 07:38 |
Ehrlich gesagt, kann ich ohne direkten Zugang jetzt kaum noch was sagen. Das klingt alles sehr nach Firewall-Probleme o.ä. Vielleicht auch die Bridge. Allerdings scheint ja ohne IPsec alles zu laufen. Dennoch sind diese Probleme sehr ungewöhnlich und ich habe aus der Ferne keine Idee mehr.
Gruß,
Ralf
|
| RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: Openwrt/Openswan... | chrisidc ( ---.162.66.68) | 17 Dec 2009 09:27 |
also es scheint als hätte ich das Problem durch einen downgrade lösen können.
Diese doppelten Routingeinträge waren anscheinend das Problem:
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
Diese treten auf, wenn man:
whiterussian rc6 mit openswan_2.4.6-1_mipsel.ipk verwendet
whiterussian rc6 mit openswan_2.4.4-1_mipsel.ipk hat diese doppelten Routingeinträge zwar nicht, aber trotzdem gibts ähnliche Probleme
whiterussian rc5 mit openswan_2.4.4-1_mipsel.ipk funktioniert soweit mal kurz angetestet ohne Probleme.
ich habe aber leider die whiterussian final noch nicht probiert (weil ich dachte der Ordner "newest" ist gleich wie rc6, aber dem ist aber anscheinend doch nicht so).
wie auch immer, problem ist eigentlich mit downgrade auf rc5 und openswan_2.4.4-1 gelöst.
|
| RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: RE: Openwrt/Open... | chrisidc ( ---.23.11.vie.surfer.at) | 17 Dec 2009 18:29 |
Whiterussian RC5 mit openswan_2.4.4-1_mipsel.ipk funktioniert auch wenn ein Router (quasi als Internet-Simulation) dazwischen ist.
Client-Seite1 192.168.1.1/24 Openwrt1 10.0.1.1 === 10.0.1.254 Router 10.0.2.254 === 10.0.2.1 Openwrt2 192.168.2.1/24 Client-Seite2
Anbei die Konfiguration (ist auf beiden gleich).
####################################################
root@openwrt1:/etc# more ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
plutodebug="none"
klipsdebug="none"
nat_traversal=no
interfaces=%defaultroute
# Add connections here
conn TestVPN
type = tunnel
left = 10.0.1.1
leftsubnet = 192.168.1.0/255.255.255.0
leftnexthop=10.0.1.254
leftsourceip=192.168.1.1
right = 10.0.2.1
rightsubnet = 192.168.2.0/255.255.255.0
rightnexthop=10.0.2.254
rightsourceip=192.168.2.1
keyexchange = ike
auth = esp
authby = secret
pfs = yes
auto = start
keyingtries = %forever
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
####################################################
####################################################
root@openwrt1:/etc# more ipsec.secrets
# PSK for tunnel from specific ip to specific ip
#192.168.3.2 192.168.3.1: PSK "abc123"
# PSK for tunnel from any ip to any ip
: PSK "meinpassword"
####################################################
Eine Frage hätte ich allerdings noch. Warum muß man eigentlich leftsourceip und rightsourceip angeben?
Wenn man das nämlich nicht angibt, bekommt man keinen icmp reply zurück.
|
17 Oct 2008: