24.07.2011, aktualisiert am 18.10.2012

10164

M0n0wall - IPSec Tunnel steht aber keine Verbindung ins LAN

Tja - nachdem ich mich hier https://www.administrator.de/index.php?content=169644 habe überzeugen lassen, meinen Netgear Router gegen eine m0n0wall auszutauschen, habe ich jetzt Schwierigkeiten, die zuvor funktionierende VPN-Verbindung auch auf der m0n0wall zum Laufen zu bringen. Vielleicht kann mir ja jemand hier auf die Sprünge helfen.

Die m0n0wall sitzt hinter einem Speedport Modem.

Die m0n0wall hat die IP 192.168.2.100
Das Lan liegt im Netz 192.168.2.0/24
Die m0n0wall fungiert als DHCP-Server und vergibt IPs im Bereich 192.168.2.11 - 192.168.2.99.
Einige IPs im Bereich von 192.168.2.1 bis 192.168.2.9 sind anhand der Mac-Adressen fest vergeben (z.B. Modem 192.168.2.1, WLAN Access Point 192.168.2.2, NAS 192.168.2.3, PC 192.168.2.4).

Innerhalb des LANs funktioniert alles wie es soll.

Wenn ich jetzt versuche, eine VPN-Verbindung aufzubauen, klappt das nicht.

Der Rechner, von dem ich via VPN zum LAN hinter der m0n0wall eine Verbindung aufbauen möchte, ist via UMTS (Vodafone) online (hat also keine feste IP)

Die VPN-Verbindung habe ich wie im m0n0wall-Handbuch beschrieben aufgesetzt.

Als VPN Client nutze ich Shrew Soft. Bei der Konfiguration des Clients habe ich mich an die Anleitung auf der Seite von Shrew Soft orientiert; die Konfiguration sieht im Detail wie folgt aus:

n:network-ike-port:500
n:network-natt-port:4500
n:network-natt-rate:30
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:0
n:network-notify-enable:1
n:client-wins-used:0
n:client-wins-auto:0
n:client-dns-used:0
n:client-dns-auto:0
n:client-splitdns-used:0
n:client-splitdns-auto:0
n:phase1-dhgroup:2
n:phase1-life-secs:54600
n:phase1-life-kbytes:0
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-list-auto:0
n:client-addr-auto:0
n:version:2
n:network-mtu-size:1380
n:policy-nailed:0
s:client-saved-username:
n:vendor-chkpt-enable:0
s:network-host:*****.********.***
s:client-auto-mode:pull
s:client-iface:virtual
s:client-ip-addr:192.168.2.9
s:client-ip-mask:255.255.255.0
s:network-natt-mode:enable
s:network-frag-mode:disable
s:auth-method:mutual-psk
s:ident-client-type:fqdn
s:ident-server-type:address
s:ident-client-data:*****.*******.***
b:auth-mutual-psk: *************
s:phase1-exchange:aggressive
s:phase1-cipher:3des
s:phase1-hash:sha1
s:phase2-transform:esp-3des
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
s:policy-level:auto
s:policy-list-include:192.168.2.0 / 255.255.255.0

Die Firewall-Einstellungen der m0n0wall sehen wie in einem hier beschriebenen Tutorial aus:

Wenn ich mich über den Shrew Soft Client verbinde, wird der Tunnel aufgebaut:

Jedoch kann ich mich mit dem LAN nicht verbinden bzw. keine Adresse dort anpingen.

Das m0n0wall Log zeit mir ebenfalls, daß der Tunnel steht:

Jul 24 19:54:31	racoon: INFO: respond new phase 1 negotiation: 87.152.21.135[500]<=>80.226.24.4[163]
Jul 24 19:54:31	racoon: INFO: begin Aggressive mode.
Jul 24 19:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jul 24 19:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
Jul 24 19:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 24 19:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Jul 24 19:54:31	racoon: INFO: received Vendor ID: RFC 3947
Jul 24 19:54:31	racoon: INFO: received Vendor ID: DPD
Jul 24 19:54:31	racoon: INFO: received Vendor ID: CISCO-UNITY
Jul 24 19:54:31	racoon: NOTIFY: the packet is retransmitted by 80.226.24.4[163] (1).
Jul 24 19:54:31	racoon: INFO: ISAKMP-SA established 87.152.21.135[500]-80.226.24.4[163] spi:75abff3a6aaaa2ff:f522593af14db6af

Das m0n0wall Firewall-Log zeigt mir zwar blockierte Verbindungen, die möglicherweise von Breitband Broadcasts meines Speedport Modems stammen, die ich aber nicht in Zusammenhang mit meinem VPN Tunnel bringen kann.

Langer Rede kurzer Sinn - als Netzwerk-Laie bin ich (wieder mal) mit meinem Latein (und meinen Nerven) am Ende und ich hoffe inständig, daß mir jemand auf die Sprünge helfen kann.

Ganz herzlichen Dank im voraus!
Jürgen

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 170328

Url: https://administrator.de/contentid/170328

Ausgedruckt am: 22.11.2024 um 20:11 Uhr

13 Kommentare

Neuester Kommentar

wahrscheinlich blockt Vodafone die ipsec-Verbindungen, mußt mal nachfragen.

Gruß, Arch Stanton

Nein, denn über denselben mobilen Rechner kann/konnte ich mich problemlos per VPN (mit dem Netgear Router als Endpunkt) mit dem lokalen LAN verbinden.

Ich vermute eher, da steckt irgendein ganz dummer Konfigurationsfehler von mir dahinter.

ok, habe gerade gesehen, daß das Speedport-Modem eine IP in Deinem Netz hat. Ich würde den Speedport als Modem nutzen und die Einwahl ins Internet durch die Monowall bewerkstelligen. Vielleicht liegt es daran, zumal du dann alle Protokolle am Spedport (ipsec und co) weiterleiten müsstest.

Das Speedport arbeitet ausschließlich als Modem (PPPoE passthrough); die Einwahl läuft über die m0n0wall. Die Verbindung aus meinem LAN ins Netz (also nach außen) funktioniert mit der m0n0wall problemlos. Ich kann versuchen, dem Speedport eine IP außerhalb meines LAN Netzes zu geben. Ob das etwas ändert, werde ich ja sehen.

Das ist mit an Sicherheit grenzender Wahrscheinlichkeit eine fehlenden Firewall Regel ! Hast du die Tips dazu in diesem Tutorial beachtet:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Du musst explizit den Tunneltraffic erlauben.

Ein Modem braucht aber keine IP im LAN. Nur wenn die Internetverbindung eines Speedports über LAN weitergereicht werden soll, ist eine solche von Nöten...

Hallo aqui,

ja, an das Tutorial habe ich mich gehalten.

Als Firewall Regeln sind definiert:

WAN:
----
UDP 	 * 	 * 	 WAN address 	 500 	 IPSec ESP IKE erlauben  			
UDP 	 * 	 * 	 WAN address 	 4500 	 IPSec ESP NAT-T erlauben  			
ESP 	 * 	 * 	 WAN address 	 * 	 IPSec ESP erlauben

LAN:
----
* 	 LAN net 	 * 	 * 	 * 	 Default LAN -> any 

IPsec VPN:
----------
* 	 * 	 * 	 * 	 * 	 Default IPsec VPN

Den Fehler in meinem Posting oben (fälschlicherweise Port 5000 statt 500) hatte ich natürlich gleich bemerkt und längst korrigiert.

Ich habe jetzt noch ein wenig weiter getestet und mir die Logs zum Tunnelaufbau näher angesehen:

Mit der vorgeschlagenen Einstellung im Client use existing adapter and current address erhalte ich nach dem Tunnelaufbau:

Jul 25 09:08:16	racoon: INFO: respond new phase 1 negotiation: 87.155.123.246[500]<=>80.226.24.3[268]
Jul 25 09:08:16	racoon: INFO: begin Aggressive mode.
Jul 25 09:08:16	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jul 25 09:08:16	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
Jul 25 09:08:16	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 25 09:08:16	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Jul 25 09:08:16	racoon: INFO: received Vendor ID: RFC 3947
Jul 25 09:08:16	racoon: INFO: received Vendor ID: DPD
Jul 25 09:08:16	racoon: INFO: received Vendor ID: CISCO-UNITY
Jul 25 09:08:16	racoon: NOTIFY: the packet is retransmitted by 80.226.24.3[268] (1).
Jul 25 09:08:16	racoon: INFO: ISAKMP-SA established 87.155.123.246[500]-80.226.24.3[268] spi:1f4225bdbee65a02:eb3673685bf1ce7f

Nach dem ersten (erfolglosen) Ping tauchen folgende Meldungen auf:

Jul 25 09:09:12	racoon: INFO: respond new phase 2 negotiation: 87.155.123.246[500]<=>80.226.24.3[268]
Jul 25 09:09:12	racoon: INFO: no policy found, try to generate the policy : 10.230.222.83/32 192.168.2.0/24 proto=any dir=in
Jul 25 09:09:12	racoon: NOTIFY: the packet is retransmitted by 80.226.24.3[268] (1).
Jul 25 09:09:12	racoon: ERROR: wrong state 8.
Jul 25 09:09:12	racoon: ERROR: failed to pre-process packet.
Jul 25 09:09:12	racoon: INFO: IPsec-SA established: ESP/Tunnel 80.226.24.3->87.155.123.246 spi=57194317(0x368b74d)
Jul 25 09:09:12	racoon: INFO: IPsec-SA established: ESP/Tunnel 87.155.123.246[500]->80.226.24.3[268] spi=745334426(0x2c6ce69a)
Jul 25 09:09:12	racoon: ERROR: such policy does not already exist: "10.230.222.83/32 192.168.2.0/24 proto=any dir=in"  
Jul 25 09:09:12	racoon: ERROR: such policy does not already exist: "192.168.2.0/24 10.230.222.83/32 proto=any dir=out"  

ipconfig /all auf dem Client-Rechner liefert

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : Ikarus
   Prim„res DNS-Suffix . . . . . . . : 
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Mobiler Breitbandadapter Mobile Breitbandverbindung:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : F3507g Mobile Broadband Driver
   Physikalische Adresse . . . . . . : 02-80-37-EC-02-00
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::65df:355f:cd01:a357%16(Bevorzugt) 
   IPv4-Adresse  . . . . . . . . . . : 10.230.222.83(Bevorzugt) 
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 10.230.222.82
   DHCPv6-IAID . . . . . . . . . . . : 251822135
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-16-DE-21-00-1F-16-35-38-FC
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: local
   Beschreibung. . . . . . . . . . . : Intel(R) WiFi Link 5300 AGN #2
   Physikalische Adresse . . . . . . : 00-21-6A-91-BD-A6
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: netgear.com
   Beschreibung. . . . . . . . . . . : Intel(R) 82567LM-Gigabit-Netzwerkverbindung
   Physikalische Adresse . . . . . . : 00-1F-16-35-3A-A2
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.local:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{0234F871-DBAB-43CF-B07F-D17B29409629}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2001:0:5ef5:79fb:1d:304f:f519:21ac(Bevorzugt) 
   Verbindungslokale IPv6-Adresse  . : fe80::1d:304f:f519:21ac%15(Bevorzugt) 
   Standardgateway . . . . . . . . . : ::
   NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Wenn ich für dem Client über Use a virtual adapter and assigned address die z.B. die Adresse 10.1.2.10/255.255.255.0 zuweise, sieht ipconfig /all wie erwartet aus:

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : Ikarus
   Prim„res DNS-Suffix . . . . . . . : 
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Ethernet-Adapter LAN-Verbindung* 2:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Shrew Soft Virtual Adapter
   Physikalische Adresse . . . . . . : AA-AA-AA-AC-A4-00
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::110e:26a8:f77a:47c2%17(Bevorzugt) 
   IPv4-Adresse  . . . . . . . . . . : 10.1.2.10(Bevorzugt) 
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 
   DHCPv6-IAID . . . . . . . . . . . : 598387370
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-16-DE-21-00-1F-16-35-38-FC
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Mobiler Breitbandadapter Mobile Breitbandverbindung:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : F3507g Mobile Broadband Driver
   Physikalische Adresse . . . . . . : 02-80-37-EC-02-00
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::65df:355f:cd01:a357%16(Bevorzugt) 
   IPv4-Adresse  . . . . . . . . . . : 10.230.222.83(Bevorzugt) 
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 10.230.222.82
   DHCPv6-IAID . . . . . . . . . . . : 251822135
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-16-DE-21-00-1F-16-35-38-FC
   DNS-Server  . . . . . . . . . . . : 139.7.30.125
   NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: local
   Beschreibung. . . . . . . . . . . : Intel(R) WiFi Link 5300 AGN #2
   Physikalische Adresse . . . . . . : 00-21-6A-91-BD-A6
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: netgear.com
   Beschreibung. . . . . . . . . . . : Intel(R) 82567LM-Gigabit-Netzwerkverbindung
   Physikalische Adresse . . . . . . : 00-1F-16-35-3A-A2
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.local:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{0234F871-DBAB-43CF-B07F-D17B29409629}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{4FCE77F4-5F11-48FF-B385-B576C11BC8E7}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2001:0:5ef5:79fb:1d:304f:f519:21ac(Bevorzugt) 
   Verbindungslokale IPv6-Adresse  . : fe80::1d:304f:f519:21ac%15(Bevorzugt) 
   Standardgateway . . . . . . . . . : ::
   NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Die m0n0wall Logs liefern in diesem Fall

Jul 25 09:18:32	racoon: INFO: respond new phase 1 negotiation: 87.155.123.246[500]<=>80.226.24.3[268]
Jul 25 09:18:32	racoon: INFO: begin Aggressive mode.
Jul 25 09:18:32	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jul 25 09:18:32	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
Jul 25 09:18:32	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 25 09:18:32	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Jul 25 09:18:32	racoon: INFO: received Vendor ID: RFC 3947
Jul 25 09:18:32	racoon: INFO: received Vendor ID: DPD
Jul 25 09:18:32	racoon: INFO: received Vendor ID: CISCO-UNITY
Jul 25 09:18:32	racoon: INFO: ISAKMP-SA established 87.155.123.246[500]-80.226.24.3[268] spi:c816c8608580cbdc:5c655561d303c0dc
Jul 25 09:18:32	racoon: INFO: purging spi=745334426.
Jul 25 09:18:32	racoon: INFO: generated policy, deleting it.
Jul 25 09:18:32	racoon: INFO: purging spi=57194317.

und nach erfolglosem Ping

Jul 25 09:19:26	racoon: INFO: respond new phase 2 negotiation: 87.155.123.246[500]<=>80.226.24.3[268]
Jul 25 09:19:26	racoon: INFO: no policy found, try to generate the policy : 10.1.2.10/32 192.168.2.0/24 proto=any dir=in
Jul 25 09:19:26	racoon: INFO: IPsec-SA established: ESP/Tunnel 80.226.24.3->87.155.123.246 spi=109945213(0x68da17d)
Jul 25 09:19:26	racoon: INFO: IPsec-SA established: ESP/Tunnel 87.155.123.246[500]->80.226.24.3[268] spi=470581643(0x1c0c818b)
Jul 25 09:19:26	racoon: ERROR: such policy does not already exist: "10.1.2.10/32 192.168.2.0/24 proto=any dir=in"  
Jul 25 09:19:26	racoon: ERROR: such policy does not already exist: "192.168.2.0/24 10.1.2.10/32 proto=any dir=out"  

Die Fehlermeldungen

racoon: ERROR: such policy does not already exist: "10.1.2.10/32 192.168.2.0/24 proto=any dir=in"
racoon: ERROR: such policy does not already exist: "192.168.2.0/24 10.1.2.10/32 proto=any dir=out"

verstehe ich nicht wirklich.

Ich muß doch - wenn ich die Anleitungen, die ich gelesen habe, richtig verstehe, selbst aktiv keine Policies in der m0n0wall anlegen, oder?

Ach ja - Deaktivieren der Windows Firewall auf dem Client-Rechener ändert an den obigen Ergebnissen erwartungsgemäß nichts.

Ich bin langsam echt am Ende. Sind die Tomaten auf den Augen wirklich so groß oder liegt da ein anderes grundsätzliches Problem vor??

Die IP wird von mir nicht explizit zugewiesen. Das Speedport ist ganz normal an den WAN-Port der m0n0wall angeschlossen. Bei der 192.168.2.1 handelt es sich um die standardmäßig vergebene IP für das Gerät.

So - was lange währt...

Aufgrund der Tatsache, daß Vodafone Websessions (damit geht der mobile Rechner über UMTS online) keine öffentlichen IPs vergibt, mußte ich

A) auf der m0n0wall Konfiguration unter VPN: IPsec: Mobile clients Enable NAT Traversal (NAT-T) aktivieren und

B) beim VPN Client (Shrew Soft) unter Local Host angeben Use a virtual adapter and assigned address

Beim Ausprobieren hatte ich zwar beide Optionen versucht, aber leider zunächst nicht gleichzeitig.

NAT Traversal ist klar weil du den doofen Speedport als Router laufen lässt. Dadurch hast du schon vor der Monowall einen NAT Router über den die VPN Verbindung so normalerweise nicht rüberkommt ohne NAT Traversal.
Diese konstellation ist auch nicht besonders intelligent und da hast du nicht wirklich nachgedacht oder aus Unwissenheit schlicht so gelassen.
Sinnvoller wäre es gewesen den Speedport in seinem Setup in den Nur Modem Modus zu schalten.
Das heisst dort PPPoE Passthrough.
Damit musst du die PPPoE Zugangsdaten dann auf der Monowall konfigurieren und hast die öffentliche IP an der Monowall. Für VPN Szenarien erheblich besser und einfacher zu managen. Zumal entfällt dann die NAT Problematik ebenfalls.
Solltest du mal drüber nachdenekn das so entsprechend zu ändern.... !

Laut seines Posts weiter oben ist das nicht der Fall. Er sagt, er lässt den Speedport nur im Modem-Modus mit PPPoE laufen... Das Problem ist, dass im Vodafone-Netz meistens private Adressen verteilt werden. Das heißt, selbst wenn sich die m0n0wall selbst einwählt, so bekommt sie doch keine öffentliche IP...

Zitat von @kingkong:

Laut seines Posts weiter oben ist das nicht der Fall. Er sagt, er lässt den Speedport nur im Modem-Modus mit PPPoE laufen...
Das Problem ist, dass im Vodafone-Netz meistens private Adressen verteilt werden. Das heißt, selbst wenn sich die m0n0wall
selbst einwählt, so bekommt sie doch keine öffentliche IP...

Ja, genauso ist es. Vodafone Websessions war halt für mein Nutzungsprofil am preiswertesten. Der von mir für's Konfigurieren aufgewandte Mehraufwand hat mir immerhin zu einem besseren Verständnis der Problematik verholfen.

OK, wenn das so ist und Provider spezifisch, dann ist NAT Traversal für dich zwingend. Ist so oder so besser das immer zu aktivieren, denn dann sind NAT Firewalls keine Hürde mehr für dich !

gelöst Frage Netzwerke

Mehr von cantor

AP mit zwei VLANs - Verständnisfrage und notwendige Switch-Konfiguration (NetGear GS10xE)cantor - 6 Kommentare

Umstellung eines bestehenden Netzwerkes samt ISDN-Anschluss auf VOIPcantor - 14 Kommentare

(pfSense) Rechner im LAN nur Zugriff auf WAN erlaubencantor - 15 Kommentare

Dynamic DNS und pfSense - IP über custom URL aktualisierencantor - 7 Kommentare

Heiß diskutiert