VPN geht nur in eine Richtung

maegl · 14. Februar 2008

Hallo zusammen,

ich häng grad in der VPN Konfig fest.

Ich hab eine Zentrale ( feste IP / T-DSL) ASA5510, mit zwei Aussenstellen ASA5505

(feste IP / Arcor).

Wenn ich von der Zentrale den Tunnel aufbaue klappt es ohne Probleme. Baut die Aussenstelle den Tunnel auf, gehts nicht. Der Tunnel kommt hoch und die Aussenstelle kann auch Pakete Senden, empfängt aber keine. :confused: Ich find einfach den Fehler nicht.

Viele Grüße,

Maegl

Hier die Konfig der Zentrale:

ASA Version 8.0(3)

!

hostname ASA-BO-ECHING

names

!

interface Ethernet0/0

nameif outside

security-level 0

pppoe client vpdn group tdsl

ip address pppoe setroute

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 192.168.10.254 255.255.255.0

!

clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00

access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.4.0 255.255.255.0

access-list splittunnel standard permit 192.168.10.0 255.255.255.0

access-list VPNRG extended permit ip 192.168.10.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list VPNBA extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

pager lines 24

logging enable

logging asdm informational

mtu outside 1500

mtu inside 1500

ip local pool vpnclient 192.168.4.1-192.168.4.30

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

crypto ipsec transform-set vpnboeching esp-3des esp-md5-hmac

crypto dynamic-map rtpdynmap 10 set transform-set vpnboeching

crypto map VPNBO 10 ipsec-isakmp dynamic rtpdynmap

crypto map VPNBO 20 match address VPNRG

crypto map VPNBO 20 set peer X.X.X.X

crypto map VPNBO 20 set transform-set vpnboeching

crypto map VPNBO 20 set reverse-route

crypto map VPNBO 30 match address VPNBA

crypto map VPNBO 30 set peer Y.Y.Y.Y

crypto map VPNBO 30 set transform-set vpnboeching

crypto map VPNBO interface outside

crypto isakmp enable outside

crypto isakmp policy 20

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

no crypto isakmp nat-traversal

telnet timeout 5

management-access inside

vpdn group tdsl request dialout pppoe

vpdn group tdsl

vpdn group tdsl ppp authentication pap

vpdn username

dhcp-client client-id interface management

dhcpd auto_config outside

group-policy vpncl internal

group-policy vpncl attributes

dns-server value 192.168.10.36

vpn-idle-timeout 20

split-tunnel-policy tunnelspecified

split-tunnel-network-list value splittunnel

tunnel-group DefaultL2LGroup ipsec-attributes

pre-shared-key *

tunnel-group vpnclientbo type remote-access

tunnel-group vpnclientbo general-attributes

address-pool vpnclient

authorization-server-group LOCAL

default-group-policy vpncl

tunnel-group vpnclientbo ipsec-attributes

pre-shared-key *

tunnel-group x.x.x.x type ipsec-l2l

tunnel-group x.x.x.x ipsec-attributes

pre-shared-key *

tunnel-group y.y.y.y type ipsec-l2l

tunnel-group y.y.y.y ipsec-attributes

pre-shared-key *

maegl · 14. Februar 2008

Hier die Konfig von einer Aussenstelle:

ASA Version 8.0(3)

!

interface Vlan1

nameif inside

security-level 100

ip address 192.168.2.1 255.255.255.0

!

interface Vlan2

nameif outside

security-level 0

pppoe client vpdn group Arcor3

ip address pppoe setroute

!

interface Ethernet0/0

switchport access vlan 2

!

interface Ethernet0/1

!

interface Ethernet0/2

!

interface Ethernet0/3

!

interface Ethernet0/4

!

interface Ethernet0/5

!

interface Ethernet0/6

!

interface Ethernet0/7

ftp mode passive

clock timezone CEST 1

clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00

dns server-group DefaultDNS

access-list nonat extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-603.bin

no asdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec transform-set boregensburg esp-3des esp-md5-hmac

crypto map boreg 10 match address VPN

crypto map boreg 10 set peer z.z.z.z

crypto map boreg 10 set transform-set boregensburg

crypto map boreg 10 set reverse-route

crypto map boreg interface outside

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

telnet timeout 5

ssh 192.168.2.0 255.255.255.0 inside

ssh 217.91.108.63 255.255.255.255 outside

ssh 217.7.187.110 255.255.255.255 outside

ssh timeout 30

console timeout 0

management-access inside

vpdn group Arcor3 request dialout pppoe

vpdn group Arcor3 ************

vpdn group Arcor3 ppp authentication pap

vpdn username data.arcor/**********************

dhcpd dns 192.168.10.36 145.253.2.75

dhcpd auto_config outside

!

dhcpd address 192.168.2.2-192.168.2.32 inside

dhcpd dns 192.168.10.36 145.253.2.75 interface inside

dhcpd enable inside

!

threat-detection basic-threat

threat-detection statistics access-list

tunnel-group z.z.z.z type ipsec-l2l

tunnel-group z.z.z.z ipsec-attributes

pre-shared-key *

!

hegl · 14. Februar 2008

Kontrolliere im ASDM im Connection Profile unter Advanced\Crypto Map Entry ob der Connection Type auf bidirectional steht. Wenn ja, schalte das logging im ASDM ein und filtere auf die IP.

Was ich in der config nicht verstehe, ist die ACL splittunnel!

Setze die doch mal testweise auf inactive.

maegl · 14. Februar 2008

Die ACL splittunnel ist für die VPN Clients. Hab die rausgenommen.

Ändert aber nichts.

Auf bidirectional steht der Tunnel.

Wenn ich von der Aussenstelle in die Zentrale pinge:

Im log ist folgender Fehler drin:

IKE Initiator unable to find policy: Intf outside, Src: 192.168.10.47, Dst: 192.168.2.2

mr._oiso · 14. Februar 2008

Hi maegl,

hast Du nach dem Aufbau des Tunnels nur nen Ping geschickt, um den Tunnel zu testen ?

Erweitere mal die IPSec Policy um ICMP

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

+

access-list VPN extended permit icmp 192.168.2.0 255.255.255.0 192.168.10.0/24

Auf beiden Seiten !

Poste mal nen: debug crypto isakmp & debug crypto ipsec (vom Tunnelaufbau bis über Phase 2 hinweg)

und nen show crypto ipsec sa !

Greez

Mr. Oiso

hegl · 15. Februar 2008

Hi maegl,

hast Du nach dem Aufbau des Tunnels nur nen Ping geschickt, um den Tunnel zu testen ?

Erweitere mal die IPSec Policy um ICMP

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

+

access-list VPN extended permit icmp 192.168.2.0 255.255.255.0 192.168.10.0/24

Auf beiden Seiten !

Sorry, aber meinst Du doppelt gemoppelt hält besser?

Erstens hat er die ACL schon und

zweitens, wenn er in der ACL ip freigibt, muss er nicht auch noch icmp freigeben, da ja bekanntlich icmp in ip drin ist !!!

@maegl: Hast Du irgendein inspection (Service Policy) konfiguriert?

maegl · 15. Februar 2008

Der Debug von der Zentrale und Aussenstelle im Anhang.

Inspections hab ich ( noch) nichts Konfiguriert, ausser dem Standard.

Zentrale:

class-map inspection_default

match default-inspection-traffic

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

!

service-policy global_policy global

Aussenstelle:

class-map inspection_default

match default-inspection-traffic

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

!

service-policy global_policy global

debugzentrale.txt

debugaussenstelle.txt

maegl · 15. Februar 2008

Hier noch der sh crpyto ipsec sa

interface: outside

Crypto map tag: VPNBO, seq num: 30, local addr: x.x.x.x

access-list VPNBA permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)

current_peer: x.x.x.x

#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3

#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 3, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x

path mtu 1492, ipsec overhead 58, media mtu 1500

current outbound spi: 724CF04F

inbound esp sas:

spi: 0xF4DFF1C3 (4108317123)

transform: esp-3des esp-md5-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 159744, crypto-map: VPNBO

sa timing: remaining key lifetime (kB/sec): (4274999/28441)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x724CF04F (1917644879)

transform: esp-3des esp-md5-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 159744, crypto-map: VPNBO

sa timing: remaining key lifetime (kB/sec): (4274999/28441)

IV size: 8 bytes

replay detection support: Y

Crypto map tag: VPNBO, seq num: 20, local addr: x.x.x.x

access-list VPNRG permit ip 192.168.10.0 255.255.255.0 192.168.2.0 255.255.255.0

local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)

current_peer: 88.79.83.72

#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x

path mtu 1492, ipsec overhead 58, media mtu 1500

current outbound spi: 0A038B8F

inbound esp sas:

spi: 0xCE9FA9D4 (3466570196)

transform: esp-3des esp-md5-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 155648, crypto-map: VPNBO

sa timing: remaining key lifetime (kB/sec): (4274999/28379)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x0A038B8F (168004495)

transform: esp-3des esp-md5-hmac none

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 155648, crypto-map: VPNBO

sa timing: remaining key lifetime (kB/sec): (4274999/28379)

IV size: 8 bytes

replay detection support: Y

hegl · 15. Februar 2008

Nur so als Tipp: editiere dein letztes Posting und x-e die VPN-Peer-IP´s aus!

Leider kann ich mit dem Output der SA´s nicht viel anfangen. Sie bestätigen mir nur, dass der Tunnel steht. Vielleicht weiß aber ein anderer mehr?

Ob die anderen beiden debugs uns weiterbringen kann ich auch nicht beurteilen, da ich sooo tief auch nicht in der Materie stecke. M.E. sieht man da auch nur die interessanten Dinge für den Tunnel selbst und keine Berchtigungsgeschichten.

Hast Du denn nun schon mal den LogViewer im ASDM eingeschaltet und auf die IP getriggert?

mr._oiso · 18. Februar 2008

Hi maegl,

jo, jo, ich habe mir etwas viel Zeit gelassen, sorry.

Aber ich denke mal ich kenne die Lösung.

Pack doch mal bitte Deine

crypto map VPNBO 10 ipsec-isakmp dynamic rtpdynmap

an das Ende der map VPNBO

Ich bin mir nicht sicher, ob der "reverse-route" für den

Tunnel zu stande kommt, daher würde ich nach Cisco Beispiel

vorgehen ! Demnach die dynmap immer ans absolute Ende der map,

welche am Outside hängt.

Die Reihenfolge der Crypto map würde ich immer nach der Genauigkeit des

Machting's aufbauen.

Je mehr Parameter für die Policy matchen, desto niedriger die ID

crypto ipsec transform-set vpnboeching esp-3des esp-md5-hmac

crypto dynamic-map rtpdynmap 10 set transform-set vpnboeching

crypto map VPNBO 20 match address VPNRG

crypto map VPNBO 20 set peer X.X.X.X

crypto map VPNBO 20 set transform-set vpnboeching

crypto map VPNBO 20 set reverse-route

crypto map VPNBO 30 match address VPNBA

crypto map VPNBO 30 set peer Y.Y.Y.Y

crypto map VPNBO 30 set transform-set vpnboeching

crypto map VPNBO 40 ipsec-isakmp dynamic rtpdynmap

crypto map VPNBO interface outside

crypto isakmp enable outside

crypto isakmp policy 20

Hier das Beispiel von Cisco

!--- Configuration of IPsec Phase 2

crypto ipsec transform-set myset esp-3des esp-sha-hmac

!--- IPsec configuration for the dynamic LAN-to-LAN tunnel

crypto dynamic-map ezvpn 30 set transform-set myset

!--- IPsec configuration for the static LAN-to-LAN tunnel

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer 172.16.1.1

crypto map outside_map 20 set transform-set myset

!--- IPsec configuration that binds dynamic map to crypto map

crypto map outside_map 65535 ipsec-isakmp dynamic ezvpn

!--- Crypto map applied to the outside interface of the ASA

crypto map outside_map interface outside

isakmp enable outside

Sorry, aber meinst Du doppelt gemoppelt hält besser?
Erstens hat er die ACL schon und

zweitens, wenn er in der ACL ip freigibt, muss er nicht auch noch icmp freigeben, da ja bekanntlich icmp in ip drin ist !!!

Erstens: Doppelt wäre gewesen,....

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

und überhaupt,

ICMP war noch nie "in IP drin" .............. !!! (wie sich das schon anhört) :suspect:

Refer to:

RFC 792

RFC 1122 Requirements for Internet Hosts -- Communication Layers

Zitat RFC1122

ICMP is a control protocol that is considered to be an

integral part of IP, although it is architecturally

layered upon IP, i.e., it uses IP to carry its data end-

to-end just as a transport protocol like TCP or UDP does.

ICMP provides error reporting, congestion reporting, and

first-hop gateway redirection.

IGMP is an Internet layer protocol used for establishing

dynamic host groups for IP multicasting.

The Internet layer protocols IP, ICMP, and IGMP are

discussed in Chapter 3.

ICMP also arbeitet nach wie vor auf der selben OSI Schicht wie IP, und zwar in der

Vermittlungsschicht (Layer3). Und "in IP drin" kann es daher per Definition nicht sein.

Refer to: Open Systems Interconnection Reference Model

Wenn wir nun also ein Vermittlungschicht Protokoll wie IP in eine IPSec Policy aufnehmen,

um die Grundlage der Vermittlungsart innerhalb des IPSec Tunnel festzulegen, so sei es unter Umständen auch Ratsam, ICMP mit hinzuzunehmen, damit "Deiner Meinung nach" ICMP auch innerhalb des IPSec Tunnel, weiterhin "in IP drin" sein darf ! :D

Greez

Mr. Oiso

hegl · 19. Februar 2008

Hi maegl,

jo, jo, ich habe mir etwas viel Zeit gelassen, sorry.

Aber ich denke mal ich kenne die Lösung.

Pack doch mal bitte Deine

crypto map VPNBO 10 ipsec-isakmp dynamic rtpdynmap

an das Ende der map VPNBO

Ich bin mir nicht sicher, ob der "reverse-route" für den

Tunnel zu stande kommt, daher würde ich nach Cisco Beispiel

vorgehen ! Demnach die dynmap immer ans absolute Ende der map,

welche am Outside hängt.

Die Reihenfolge der Crypto map würde ich immer nach der Genauigkeit des

Machting's aufbauen.

Je mehr Parameter für die Policy matchen, desto niedriger die ID

Hier das Beispiel von Cisco

!--- Configuration of IPsec Phase 2

crypto ipsec transform-set myset esp-3des esp-sha-hmac

!--- IPsec configuration for the dynamic LAN-to-LAN tunnel

crypto dynamic-map ezvpn 30 set transform-set myset

!--- IPsec configuration for the static LAN-to-LAN tunnel

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer 172.16.1.1

crypto map outside_map 20 set transform-set myset

!--- IPsec configuration that binds dynamic map to crypto map

crypto map outside_map 65535 ipsec-isakmp dynamic ezvpn

!--- Crypto map applied to the outside interface of the ASA

crypto map outside_map interface outside

isakmp enable outside

Hier stimme ich Dir vollkommen zu, dass die dyn. cryptomap ans Ende sollte/muss.

Aber, ist das wirklich ausschlaggebend für die site-to-site?

Ich denke, dass er so wie er´s hat "nur" Probleme beim Aufbau mit seinen Clients bekommt.

Erstens: Doppelt wäre gewesen,....

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

und überhaupt,

ICMP war noch nie "in IP drin" .............. !!! (wie sich das schon anhört) :suspect:

Refer to:

RFC 792

RFC 1122 Requirements for Internet Hosts -- Communication Layers

ICMP also arbeitet nach wie vor auf der selben OSI Schicht wie IP, und zwar in der

Vermittlungsschicht (Layer3). Und "in IP drin" kann es daher per Definition nicht sein.

Refer to: Open Systems Interconnection Reference Model

Wenn wir nun also ein Vermittlungschicht Protokoll wie IP in eine IPSec Policy aufnehmen,

um die Grundlage der Vermittlungsart innerhalb des IPSec Tunnel festzulegen, so sei es unter Umständen auch Ratsam, ICMP mit hinzuzunehmen, damit "Deiner Meinung nach" ICMP auch innerhalb des IPSec Tunnel, weiterhin "in IP drin" sein darf ! :D

Greez

Mr. Oiso

Ich lasse mich gerne eines Besseren belehren, schließlich sind wir ja alle hier, um Hilfe zu erhalten oder auch zu geben.

Bis jetzt habe ich halt die Erfahrung gemacht, dass bei einer Berechtigung von IP auch ICMP funktionierte - deshalb auch mein obiges Statement

Also lass uns nicht streiten, sondern versuchen dem Kollegen zu helfen.

Wenn ich Dir zu nahe getreten bin - sorry! ;)

Nach wie vor sehe ich aber, dass er in der Aussenstelle die ACL

access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0

schon hat und in der Zentrale diese nicht konfiguriert werden muss, da zuerst das lokale Netz und dann das remote Netz angegeben wird und das hat er ja mit

[access-list VPNRG extended permit ip 192.168.10.0 255.255.255.0 192.168.2.0 255.255.255.0

bereits getan.

@maegl: Was sacht denn jetzt das logging? Wird irgendein Fehler protokolliert?

Gruß

hegl

maegl · 19. Februar 2008

Hallo Zusammen,

soweit wir es bis jetzt getestett haben, war das der Fehler.

Die crypto map schaut jetzt so aus:

crypto map VPNBO 20 match address VPNRG

crypto map VPNBO 20 set peer x.x.x.x

crypto map VPNBO 20 set transform-set vpnboeching

crypto map VPNBO 30 match address VPNBA

crypto map VPNBO 30 set peer y.y.y.y

crypto map VPNBO 30 set transform-set vpnboeching

crypto map VPNBO 40 ipsec-isakmp dynamic rtpdynmap

crypto map VPNBO interface outside

und schon funktionierts.

Vielen Dank für eure Hilfe!!:) :)

Viele Grüße,

Maegl

hegl · 19. Februar 2008

und schon wieder was gelernt, obwohl ich es nicht verstehe :confused: :confused: :confused:

maegl · 19. Februar 2008

Geht mir nicht anders,

it´s not a bug, it´s a feature :suspect:

mr._oiso · 19. Februar 2008

Hi maegl, hi hegl,

@hegl, sorry für die ...... (Du weisst schon), ich nehme es halt gern genau ! ;)

Aber nur so erklärt sich oft vieles von alleine !

Im Debug Output gab es bis auf:

Feb 15 09:38:28 [iKEv1 DEBUG]: Group = x.x.x.x, IP = x.x.x.x, IPSec SA Proposal # 1, Transform # 1 acceptable Matches global IPSec SA entry # 10

keine Fehler, nur in diesem Eintrag ist genau zu sehen, dass die Phase 2 auf die falsche IKE Policy aufsetzt. "Matches global IPSec SA entry # 10"

Eigendlich hätte hier die # 20 stehen müssen, damit der Tunnel nach Vorgabe in beiden

Richtungen hätte funktionieren können.

Auch die Entnahme der "set reverse-route" kann die Aktion begünstigt haben, welche mir gestern Abend dann im Bett auch sinnlos erschien, weil die Policy doch anhand einer

L2L hätte direkt matchen dürfen.

Habe da anfänglich leicht dran vorbei geschaut, obwohl Du eine pppoe mit dynamic IP am outside laufen hast.

Ich dachte mir aber schon, dass Du sicherlich eine endlose "lease" bekommst, und daher war ansonsten auch alles richtig.

Eine weitere mögliche Lösung wäre gewesen:

Verwende solange es die Resourcen der Hardware zulassen unterschiedliche IKE Proposal's, um solche Fehler zu umgehen (oder bename sie einfach anders).

Richtig lustig wird es erst noch wenn man nun auch noch L2TPoverIPSec oder gar SSLVPN

Policies mit einarbeitet !

Schön, dass ich helfen konnte !

Und sollten noch Fragen offen sein, nur zu !

Nice evening !

Greez

Mr. Oiso

Anmelden

VPN geht nur in eine Richtung

Empfohlene Beiträge

maegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

hegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

mr._oiso 10

Link zu diesem Kommentar

hegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

hegl 10

Link zu diesem Kommentar

mr._oiso 10

Link zu diesem Kommentar

hegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

hegl 10

Link zu diesem Kommentar

maegl 10

Link zu diesem Kommentar

mr._oiso 10

Link zu diesem Kommentar

Schreibe einen Kommentar

Menu

Aktivitäten