14
Pix 515E NAT Policies bzw. VPN-Problem
Hallo,
ich habe eine Frage zu meinen geposteten NAT-Policies, die wir angezeigt bekommen.
Die Pix ist VPN-Server und der Tunnel endet auf dem outside.
Was bedeuten die Fehlermeldungen im Post ?
192.168.50.0 und 172.16.1.0 sind unsere beiden LAN bzw. DMZ.
Wir kommen aber mit dem Cisco VPN-Client nur ins 172.16.1.0 er Netz (DMZ)
Kann mir jemand erklären, was die Fehlermeldung genau bedeutet.
(siehe post unten)
Gruss Roland
pix515E# sh nat
NAT policies on Interface inside:
match ip inside 192.168.50.0 255.255.255.0 inside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 76
match ip inside 192.168.50.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 inside any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.253 [Interface PAT])
translate_hits = 339, untranslate_hits = 34
match ip inside 192.168.50.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
NAT policies on Interface dmz:
match ip dmz 172.16.1.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 324, untranslate_hits = 310
match ip dmz 172.16.1.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip dmz 172.16.1.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.253 [Interface PAT])
translate_hits = 62603, untranslate_hits = 4088
match ip dmz 172.16.1.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
ich habe eine Frage zu meinen geposteten NAT-Policies, die wir angezeigt bekommen.
Die Pix ist VPN-Server und der Tunnel endet auf dem outside.
Was bedeuten die Fehlermeldungen im Post ?
192.168.50.0 und 172.16.1.0 sind unsere beiden LAN bzw. DMZ.
Wir kommen aber mit dem Cisco VPN-Client nur ins 172.16.1.0 er Netz (DMZ)
Kann mir jemand erklären, was die Fehlermeldung genau bedeutet.
(siehe post unten)
Gruss Roland
pix515E# sh nat
NAT policies on Interface inside:
match ip inside 192.168.50.0 255.255.255.0 inside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 76
match ip inside 192.168.50.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 inside any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.253 [Interface PAT])
translate_hits = 339, untranslate_hits = 34
match ip inside 192.168.50.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
NAT policies on Interface dmz:
match ip dmz 172.16.1.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 324, untranslate_hits = 310
match ip dmz 172.16.1.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip dmz 172.16.1.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.253 [Interface PAT])
translate_hits = 62603, untranslate_hits = 4088
match ip dmz 172.16.1.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 75376
Url: https://administrator.de/contentid/75376
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
14 Kommentare
Neuester Kommentar
Hallo Roland,
ich habe deinen Betrag gerade erst gesehen. Ist das Problem schon gelöst?
evtl. fehlt der dazu gehörige global bzw. outside Eintrag.
Ich habe deinen Beitrag vom 21.Nov. gesehen. Da steht: global (outside) 1 192.168.200.253 netmask 255.255.255.0
Ist der Eintrag auch jetzt noch in der Konfiguration? Es scheint mir falsch zu sein eine netmask 255.255.255.0 anzugeben. Ich hätte netmask 255.255.255.255 erwartet.
Gruß Rafiki
ich habe deinen Betrag gerade erst gesehen. Ist das Problem schon gelöst?
dynamic translation to pool 3 (No matching global)
evtl. fehlt der dazu gehörige global bzw. outside Eintrag.
Ich habe deinen Beitrag vom 21.Nov. gesehen. Da steht: global (outside) 1 192.168.200.253 netmask 255.255.255.0
Ist der Eintrag auch jetzt noch in der Konfiguration? Es scheint mir falsch zu sein eine netmask 255.255.255.0 anzugeben. Ich hätte netmask 255.255.255.255 erwartet.
Gruß Rafiki
Hallo Roland,
ich habe deinen Betrag gerade erst gesehen.
Ist das Problem schon gelöst?
> dynamic translation to pool 3 (No
matching global)
evtl. fehlt der dazu gehörige global
bzw. outside Eintrag.
Ich habe deinen Beitrag vom 21.Nov. gesehen.
Da steht: global (outside) 1 192.168.200.253
netmask 255.255.255.0
Ist der Eintrag auch jetzt noch in der
Konfiguration? Es scheint mir falsch zu sein
eine netmask 255.255.255.0 anzugeben. Ich
hätte netmask 255.255.255.255 erwartet.
Gruß Rafiki
ich habe deinen Betrag gerade erst gesehen.
Ist das Problem schon gelöst?
> dynamic translation to pool 3 (No
matching global)
evtl. fehlt der dazu gehörige global
bzw. outside Eintrag.
Ich habe deinen Beitrag vom 21.Nov. gesehen.
Da steht: global (outside) 1 192.168.200.253
netmask 255.255.255.0
Ist der Eintrag auch jetzt noch in der
Konfiguration? Es scheint mir falsch zu sein
eine netmask 255.255.255.0 anzugeben. Ich
hätte netmask 255.255.255.255 erwartet.
Gruß Rafiki
Hallo Rafiki,
nein, ich konnte das Problem noch nicht lösen.
Die Pix Config hat sich aber etwas verändert seit dem Post.
Poste mal die aktuelle config und die Ausgabe von show nat.
Das Netz 172.16.1.0 ist bei uns die DMZ und 192.168.50.0 ist das LAN (Workstations, Fileserver, etc.)
Was ich nicht verstehe, dass ich mit dem Cisco VPN-Client nur in die DMZ komme, aber nicht ins LAN, ich vermutete, dass es eventuell am NAT liegt, bin im Augenblick etwas ratlos.
Gruss Roland
Ausgabe von show nat
pix515E# sh nat
NAT policies on Interface inside:
match ip inside 192.168.50.0 255.255.255.0 inside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 94
match ip inside 192.168.50.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 inside any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 339, untranslate_hits = 34
match ip inside 192.168.50.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
NAT policies on Interface dmz:
match ip dmz 172.16.1.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 351, untranslate_hits = 340
match ip dmz 172.16.1.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip dmz 172.16.1.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 70615, untranslate_hits = 6229
match ip dmz 172.16.1.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
die aktuelle Config der Pix:
- Saved
PIX Version 7.2(2)
!
hostname pix515E
domain-name mgs.me
enable password XXXXXXXXXx encrypted
names
!
interface Ethernet0
nameif outside
security-level 0
ip address dhcp setroute
!
interface Ethernet1
nameif inside
security-level 100
ip address 192.168.50.254 255.255.255.0
!
interface Ethernet2
nameif dmz
security-level 50
ip address 172.16.1.254 255.255.255.0
!
passwd XXXXXXXXXx encrypted
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
domain-name mgs.me
access-list acl-inside extended permit ip 172.16.1.0 255.255.255.0 any
access-list acl-inside extended permit ip 192.168.6.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list acl-inside extended permit tcp 192.168.6.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list inside-nat0 extended permit ip 192.168.50.0 255.255.255.0 192.168.6.0 255.255.255.0
access-list dmz-nat0 extended permit ip 172.16.1.0 255.255.255.0 192.168.6.0 255.255.255.0
access-list Local_LAN_Access standard permit 172.16.1.0 255.255.255.0
access-list Local_LAN_Access standard permit 192.168.50.0 255.255.255.0
access-list vpn-schreiber_splitTunnelAcl standard permit 172.16.1.0 255.255.255.0
access-list vpn-schreiber_splitTunnelAcl standard permit 192.168.50.0 255.255.255.0
access-list inside_access_in extended permit ip 192.168.50.0 255.255.255.0 any
access-list inside_access_in extended permit ip 192.168.6.0 255.255.255.0 192.168.50.0 255.255.255.0
access-list inside_access_in extended permit tcp 192.168.6.0 255.255.255.0 192.168.50.0 255.255.255.0
access-list outside_access_in extended permit ip 192.168.6.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list outside_access_in extended permit ip 192.168.6.0 255.255.255.0 192.168.50.0 255.255.255.0
access-list outside_access_in extended permit tcp 192.168.6.0 255.255.255.0 192.168.50.0 255.255.255.0
pager lines 24
logging enable
logging list VPN-Tunnel level warnings class vpnc
logging list VPN-Tunnel level warnings class vpnfo
logging asdm informational
mtu inside 1500
mtu outside 1500
mtu dmz 1500
ip local pool vpn-client-ips 192.168.6.1-192.168.6.254 mask 255.255.255.0
icmp unreachable rate-limit 1 burst-size 1
asdm image flash:/asdm
no asdm history enable
arp timeout 14400
global (outside) 3 192.168.200.50-192.168.200.70 netmask 255.255.255.0
nat (inside) 0 access-list inside-nat0
nat (inside) 3 192.168.50.0 255.255.255.0 dns
nat (dmz) 0 access-list dmz-nat0
nat (dmz) 3 172.16.1.0 255.255.255.0 dns
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
access-group acl-inside in interface dmz
route outside 0.0.0.0 0.0.0.0 192.168.200.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
group-policy mgs internal
group-policy mgs attributes
wins-server value 192.168.50.1 172.16.1.1
dns-server value 192.168.50.1 217.237.148.22
vpn-tunnel-protocol IPSec
default-domain value mgs.me
group-policy vpn-schreiber internal
group-policy vpn-schreiber attributes
wins-server value 192.168.50.1 192.168.50.1
dns-server value 192.168.50.1 192.168.50.1
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value vpn-schreiber_splitTunnelAcl
default-domain value mgs.me
username user-xyz password XXXXXxx encrypted privilege 0
username user-xyz-schmid attributes
vpn-group-policy vpn-schreiber
username user-abc password xxxxxxxxxxx encrypted privilege 0
username user-abc attributes
vpn-group-policy vpn-schreiber
username user-123 password xxxxxxxxxxxxx encrypted privilege 0
username user-123 attributes
vpn-group-policy vpn-schreiber
http server enable
http 172.16.1.1 255.255.255.255 dmz
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 20 set pfs
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto dynamic-map outside_dyn_map 40 set pfs
crypto dynamic-map outside_dyn_map 40 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
crypto ca certificate map DefaultCertificateMap 10
crypto ca certificate map DefaultCertificateMap 20
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp nat-traversal 20
tunnel-group mgs type ipsec-ra
tunnel-group mgs general-attributes
address-pool vpn-client-ips
default-group-policy mgs
tunnel-group mgs ipsec-attributes
pre-shared-key *
tunnel-group vpn-schreiber type ipsec-ra
tunnel-group vpn-schreiber general-attributes
address-pool (inside) vpn-client-ips
address-pool (outside) vpn-client-ips
address-pool (dmz) vpn-client-ips
address-pool vpn-client-ips
default-group-policy vpn-schreiber
tunnel-group vpn-schreiber ipsec-attributes
pre-shared-key *
tunnel-group-map enable rules
tunnel-group-map default-group vpn-schreiber
tunnel-group-map DefaultCertificateMap 10 mgs
tunnel-group-map DefaultCertificateMap 20 vpn-schreiber
telnet timeout 5
ssh 192.168.50.13 255.255.255.255 inside
ssh 80.152.212.35 255.255.255.255 outside
ssh 172.16.1.1 255.255.255.255 dmz
ssh timeout 5
console timeout 0
!
!
tftp-server inside 192.168.50.1 pix515-cfg
prompt hostname context
Cryptochecksum:xxxxxxxxxxxxx
: end
asdm image flash:/asdm
no asdm history enable
Probier bitte mal aus ob dieser Befehl deine Probleme löst:
sysopt connection permit-vpn
For traffic that enters the security appliance through a VPN tunnel and is then decrypted, use the sysopt connection permit-vpn command in global configuration mode to allow the traffic to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. To disable this feature, use the no form of this command.
Das war bis Ver. 7.1: sysopt connection permit-ipsec
Dann wissen wir ob es an den acl oder am NAT liegt.
Gruß Rafiki
sysopt connection permit-vpn
For traffic that enters the security appliance through a VPN tunnel and is then decrypted, use the sysopt connection permit-vpn command in global configuration mode to allow the traffic to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. To disable this feature, use the no form of this command.
Das war bis Ver. 7.1: sysopt connection permit-ipsec
Dann wissen wir ob es an den acl oder am NAT liegt.
Gruß Rafiki
Hallo Rafiki,
sysopt connection permit-vpn habe ich eingegeben an der Pix.
Aber nach wie vor komme ich mit dem Cisco VPN-Client nur in die dmz (172.16.1.0).
Sieht jetzt so aus:
pix515E(config)# sh run sysopt
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
sysopt connection permit-vpn
Was mir auffällt, dass bei den NAT-Policies gar keine untranslated packages ins 192.168.50.0 Netz gehen, während beim dmz netz sehr wohl. Liegt es am NAT, aber was ist falsch eingestellt.
Ausgabe sh nat:
pix515E(config)# sh nat
NAT policies on Interface inside:
match ip inside 192.168.50.0 255.255.255.0 inside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 106
match ip inside 192.168.50.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 inside any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 339, untranslate_hits = 34
match ip inside 192.168.50.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
NAT policies on Interface dmz:
match ip dmz 172.16.1.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 369, untranslate_hits = 342
match ip dmz 172.16.1.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip dmz 172.16.1.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 72921, untranslate_hits = 7227
match ip dmz 172.16.1.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
Unsere Workstations haben alle als Standard GW den SBS 2003 (AD und Exchange) und der routet den Traffic über sein Bein in die dmz raus ins Internet. Über das inside interface läuft quasi kein Traffic, wir brauchen das inside interface der Pix 515E eigentlich nur um via VPN ins 192.168.50.0 Netz an die Workstations, Fileserver etc. zu kommen.
Ausgabe von sh xlate:
pix515E(config)# sh xlate
1 in use, 248 most used
Global 192.168.200.51 Local 172.16.1.1
Gruss Roland
sysopt connection permit-vpn habe ich eingegeben an der Pix.
Aber nach wie vor komme ich mit dem Cisco VPN-Client nur in die dmz (172.16.1.0).
Sieht jetzt so aus:
pix515E(config)# sh run sysopt
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
sysopt connection permit-vpn
Was mir auffällt, dass bei den NAT-Policies gar keine untranslated packages ins 192.168.50.0 Netz gehen, während beim dmz netz sehr wohl. Liegt es am NAT, aber was ist falsch eingestellt.
Ausgabe sh nat:
pix515E(config)# sh nat
NAT policies on Interface inside:
match ip inside 192.168.50.0 255.255.255.0 inside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 106
match ip inside 192.168.50.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 inside any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
match ip inside 192.168.50.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 339, untranslate_hits = 34
match ip inside 192.168.50.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
NAT policies on Interface dmz:
match ip dmz 172.16.1.0 255.255.255.0 outside 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 369, untranslate_hits = 342
match ip dmz 172.16.1.0 255.255.255.0 dmz 192.168.6.0 255.255.255.0
NAT exempt
translate_hits = 0, untranslate_hits = 0
match ip dmz 172.16.1.0 255.255.255.0 outside any
dynamic translation to pool 3 (192.168.200.50 - 192.168.200.70)
translate_hits = 72921, untranslate_hits = 7227
match ip dmz 172.16.1.0 255.255.255.0 dmz any
dynamic translation to pool 3 (No matching global)
translate_hits = 0, untranslate_hits = 0
Unsere Workstations haben alle als Standard GW den SBS 2003 (AD und Exchange) und der routet den Traffic über sein Bein in die dmz raus ins Internet. Über das inside interface läuft quasi kein Traffic, wir brauchen das inside interface der Pix 515E eigentlich nur um via VPN ins 192.168.50.0 Netz an die Workstations, Fileserver etc. zu kommen.
Ausgabe von sh xlate:
pix515E(config)# sh xlate
1 in use, 248 most used
Global 192.168.200.51 Local 172.16.1.1
Gruss Roland
Deine NAT und Access listen habe ich mir jetzt schon 3-mal durchgelesen. Sieht eigentlich gut aus.
Hey, das könnte die Ursache sein!
Wenn ein Paket vom VPN Client an deinen Server im LAN 192.168.50.0 geht, dann hat das Paket als Absenderadresse eine 192.168.6.0 Adresse. Der Server antwortet dann, und da es nicht in seinem LAN ist wird die antwort an das default Gateway geschickt. Das ist das DMZ Interface der PIX. Die allerdings erwartet die Antwort auf dem LAN Interface.
Probiere doch bitte mal auf dem Windows Server ein den Befehl:
route add 192.168.6.0 mask 255.255.255.0 192.168.50.254
Also auf Deutsch: Das VPN Netzwerk befindet sich hinter dem LAN Interface der PIX.
Gruß Rafiki
Unsere Workstations haben alle als Standard GW den SBS 2003 (AD und Exchange) und der routet den Traffic über sein Bein in die dmz raus ins Internet. Über das inside interface läuft quasi kein Traffic, wir brauchen das inside interface der Pix 515E eigentlich nur um via VPN ins 192.168.50.0 Netz an die Workstations, Fileserver etc. zu kommen.
Hey, das könnte die Ursache sein!
Wenn ein Paket vom VPN Client an deinen Server im LAN 192.168.50.0 geht, dann hat das Paket als Absenderadresse eine 192.168.6.0 Adresse. Der Server antwortet dann, und da es nicht in seinem LAN ist wird die antwort an das default Gateway geschickt. Das ist das DMZ Interface der PIX. Die allerdings erwartet die Antwort auf dem LAN Interface.
Probiere doch bitte mal auf dem Windows Server ein den Befehl:
route add 192.168.6.0 mask 255.255.255.0 192.168.50.254
Also auf Deutsch: Das VPN Netzwerk befindet sich hinter dem LAN Interface der PIX.
Gruß Rafiki
Hallo Rafiki,
habe heute die route in den Windows Server eingetragen.
(route add 192.168.6.0 mask 255.255.255.0 192.168.50.254)
Jetzt ist etwas passiert, das ich mir im Moment nicht erklären kann.
Verbinde ich mich jetzt mit dem Cisco VPN-Client erhält der Client eine IP aus dem 172.16.1.0 er Netz.
Ich habe heute an der PIX das Authentifizieren (was ich auch vor hatte) auf unser AD (IAS) umgestellt. (vorher waren es lokal die Pix User) Das funktioniert soweit, den Tunnel kann ich mit den jeweiligen AD Benutzern, die in den Gruppen stecken, die ich dem IAS bekannt gemacht habe aufbauen.
Verstehe aber nicht, warum die Clients jetzt eine IP aus einem anderen Bereich bekommen.
Kann jetzt leider die config nicht posten, weil ich von remote z.Zt. nicht dran komme.
Werd das morgen früh aber nachholen.
Kann das mit der neuen route zusammenhängen, oder liegt es an der Authentifizierung der PIX am Radius-Server ? Muss ich gleich morgen früh nachsehen...
Gruss Roland
habe heute die route in den Windows Server eingetragen.
(route add 192.168.6.0 mask 255.255.255.0 192.168.50.254)
Jetzt ist etwas passiert, das ich mir im Moment nicht erklären kann.
Verbinde ich mich jetzt mit dem Cisco VPN-Client erhält der Client eine IP aus dem 172.16.1.0 er Netz.
Ich habe heute an der PIX das Authentifizieren (was ich auch vor hatte) auf unser AD (IAS) umgestellt. (vorher waren es lokal die Pix User) Das funktioniert soweit, den Tunnel kann ich mit den jeweiligen AD Benutzern, die in den Gruppen stecken, die ich dem IAS bekannt gemacht habe aufbauen.
Verstehe aber nicht, warum die Clients jetzt eine IP aus einem anderen Bereich bekommen.
Kann jetzt leider die config nicht posten, weil ich von remote z.Zt. nicht dran komme.
Werd das morgen früh aber nachholen.
Kann das mit der neuen route zusammenhängen, oder liegt es an der Authentifizierung der PIX am Radius-Server ? Muss ich gleich morgen früh nachsehen...
Gruss Roland
Oooops.
Ich kann mir nicht vorstellen das es an der Route liegen soll. Deshalb würde ich auf die RADIUS Konfiguration tippen. Das iat aber nur geraten denn hellsehen kann ich nicht.
Gruß Rafiki
Ich kann mir nicht vorstellen das es an der Route liegen soll. Deshalb würde ich auf die RADIUS Konfiguration tippen. Das iat aber nur geraten denn hellsehen kann ich nicht.
Gruß Rafiki
Hallo Rafiki,
es lag am Radius-Server.
Dort hatte ich ausversehen eine IP-Zuteilung eingetragen.
Jetzt bekommen die Clients wieder ihre richtigen IPs.
Gruss Roland
es lag am Radius-Server.
Dort hatte ich ausversehen eine IP-Zuteilung eingetragen.
Jetzt bekommen die Clients wieder ihre richtigen IPs.
Gruss Roland
Ist damit dein NAT Problem gelöst?
Wenn nicht, wie ist der status, was geht, was geht nicht?
hast du die sysopt angewandt?
gruß Rafiki
Wenn nicht, wie ist der status, was geht, was geht nicht?
hast du die sysopt angewandt?
gruß Rafiki
Hallo Rafiki,
jetzt ist es genau umgedreht.
Ich komme nun in das 192.168.50.0 er Netz mit dem VPN-Client rein, in das ich vorher nicht kam.
Aber dafür komme ich nicht mehr ins 172.16.1.0 er Netz.
Ob ich noch ne 2. route in den Windows Server eintragen, z.B.
route add 192.168.6.0 mask 255.255.255.0 172.16.1.254 ?
Der VPN-Client bekommt ganz wie es sein soll sein IP aus dem 192.168.6.0 er Netz
Gruss Roland
jetzt ist es genau umgedreht.
Ich komme nun in das 192.168.50.0 er Netz mit dem VPN-Client rein, in das ich vorher nicht kam.
Aber dafür komme ich nicht mehr ins 172.16.1.0 er Netz.
Ob ich noch ne 2. route in den Windows Server eintragen, z.B.
route add 192.168.6.0 mask 255.255.255.0 172.16.1.254 ?
Der VPN-Client bekommt ganz wie es sein soll sein IP aus dem 192.168.6.0 er Netz
Gruss Roland
Ob ich noch ne 2. route in den Windows
Server eintragen, z.B.
route add 192.168.6.0 mask 255.255.255.0
172.16.1.254 ?
Server eintragen, z.B.
route add 192.168.6.0 mask 255.255.255.0
172.16.1.254 ?
ne, dass brachte nichts.
Hast Du noch eine Idee ?
Gruss Roland
Ich glaube es wird nicht funktionieren eine Route für den VPN Pool zwei mal einzutragen.
Beachte bitte eine persönliche Nachricht an dich.
Gruß Rafki
Beachte bitte eine persönliche Nachricht an dich.
Gruß Rafki
Hallo Rafiki,
ich habe dir auf Deine Nachricht geantwortet.
Besten Dank.
Gruss Roland
ich habe dir auf Deine Nachricht geantwortet.
Besten Dank.
Gruss Roland
Hallo Rafiki,
jetzt ist es gelöst, es lag tatsächlich an dem Standard Gateway.
Die Brücke (route) habe ich rausgeschmissen. Jetz komme ich in beide Netze wunderbar.
Vielen Dank für das freundliche Telefongespräch heute.
Gruss Roland
jetzt ist es gelöst, es lag tatsächlich an dem Standard Gateway.
Die Brücke (route) habe ich rausgeschmissen. Jetz komme ich in beide Netze wunderbar.
Vielen Dank für das freundliche Telefongespräch heute.
Gruss Roland
