s21it21

hallo,

mm, ich wüsste nicht, dass man am client das einstellen kann. der vpn-client schaltet sich ja komplett dazwischen. darum glaube ich ehrlich gesagt nicht, dass man das am client direkt umbiegen kann.

ich kenne das nur mit dem split-tunnel. das habe ich schon x-mal bei kunden und bei mir selbst konfiguriert.

zb:

Damit wird in diesem Beispiel nur der Verkehr für das Netzwerk 192.168.1.0/24 (MYLAN) durch das VPN geleitet.

Alles andere "folgt weiterhin der Default Route des Clients" (nicht durchs VPN). Somit kann man normal weitersurfen und zwar nicht durch das VPN.

access-list intranet_splitTunnelAcl permit ip MYLAN 255.255.255.0 any

vpngroup intranet split-tunnel intranet_splitTunnelAcl

vpngroup intranet split-dns ihre.domain

Somit geht nur der Traffic mit Ziel: 192.168.1.0/24 ins VPN hinein (und zurück), der Rest geht aussen vorbei.

Hier noch weitere Infos:

Use the vpngroup split-tunnel command to enable split tunneling on the PIX Firewall. Split tunneling allows a remote VPN client simultaneous encrypted access to the corporate network and clear access to the Internet. Using the vpngroup split-tunnel command, specify the access-list name to which to associate the split tunnelling of traffic. With split tunnelling enabled, the PIX Firewall downloads its local network IP address and netmask specified within the associated access-list to the VPN Client as part of the policy push to the client. In turn, the VPN Client sends the traffic destined to the specified local PIX Firewall network via an IPSec tunnel and all other traffic in the clear. The PIX Firewall receives the IPSec-protected packet on its outside interface, decrypts it, and then sends it to its specified local network.

Siehe: http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_user_guide_chapter09186a0080106f8c.html#1055456

lg

Martin

hello,

so weit ich mich mit dem client beschäftigt habe, konfiguriert man das auf der firewall direkt (splitt-tunnel). diese konfig bekommt dann der client und man kann einerseits ins vpn hinein, aber surfen über den lokalen provider (und nicht durch das vpn).

lg

martin

Hallo,

Also grundsätzlich kann die PIX schon am Outside-Interface via DHCP eine IP-Adresse bekommen. Ob man die MAC änder kann, weiss ich leider auch nicht.

LG

Martin

hallo,

also auch ich vertraue der palette von trendmicro. ein vorteil ist auch noch, das laptops, wenn sie nicht im firmen-lan sind, pattern-files trotzdem aus dem internet herunteladen können. somit sind auch diese vom pattern-file her immer am aktuellen stand.

die web-konsole ist auch sehr gut und einfach zu bedienen. vom virenschutz her hatten wir noch nie probleme (wir hatten auch gewaltige hardcoretester --> sekräterinen, etc. *ggg*).

lg

martin

hallo,

wenn du hinter der zweiten pix hängst und ins internet über pix1 und pix2 willst, dann gibt es mehrer ansätze.

du musst wissen, dass die pix im prinzip ein nat-device ist. mit dem pdm wirst du das nicht sinnvoll hinbekommen...

von innen gesehen, musst du auf der pix1 (also auf der internen) es so einrichten, dass das interne lan auf die "externe" ip der pix1 genattet wird, genau diese ip-adresse musst du dann auf der äusseren pix2 (die ins internet) wieder natten.

andere möglichkeit ist, dass du das interne-lan auf der ersten pix nicht nattest, aber dafür direkt zur zweiten pix routest und das dann dort erst nattest. du müsstest halt das interne lan in der dmz routen bzw. von der einen pix zur anderen routen (und auch zurück).

lg

martin

hello,

ich bilde mir ein gelesen zu haben, dass man nur den gesamten vpn-traffic priorisieren kann, nicht aber bestimmte pakte innerhalb des vpns....kann aber auch falsch liegen.

check mal die cisco-seite zum theme pix ios7.

lg

martin

hallo,

also bei meiner acs-installation wurde ich bei dieser nach einem gewünschten user + pwd (admin) gefragt. dieser hat dann auch funktioniert.

mit cisco/cisco cisco/blank (also kein pwd), admin/admin, etc. hast du es schon probiert??

es ist aber auch möglich, dass du dich mit der konsole direkt am server verbindest und dabei gibt es ein paar befehle. unter anderem kann man auch einen neuen admin einrichten.

das mit dem ad stimmt schon, nur bei der ersten installation wird ein lokaler admin-user angelegt.

lg

martin

hallo,

ganz einfach:

du machst zwei fehler:

1) access-listen für hosts sind immer an dem interface zu binden, wo der traffic als ersters aufschlägt. wenn du also vom privaten-lan (inside-int) raus willst, dann musst du die access-list am internen interface freischalten.

bemerkung dazu: das design der pix ist so, dass wenn du gar keine access-list am internen interface gebunden hast, dass prinzipiell JEDER traffic raus darf (ist sec.-technisch sehr schlecht, aber das ist was anderes). ich nehme mal an (wenn ich deine access-lists unten sehe), dass das bei dir der fall ist.

2) icmp behandelt die pix NICHT statefull. das heisst die echo-replies musst du am outside interface extra wieder freischalten. deine freischaltung:

access-list in-out-icmp-nbaomsch permit icmp host 192.168.1.2 any

besagt, dass traffic vom internet auf 192.168.1.2 erlaubt wird...das ist insofern falsch, da dies ja eine nicht geroutete ip ist. darum bringt diese freischaltung absolut nichts (die privaten ips werden ja von der pix genattet (und auch das kommt darauf an, wie du das eingerichtet hast). wenn du die 501er neu gekaufst hast, ist es so, dass alles hinter der pupip vom outside-interface "versteckt" wird.

die freischaltung vorher (access-list in-out-icmp permit icmp any any) ist dabei richtig (wenn auch sehr global). denn da erlaubst du, dass icmp von aussen komplett zur pix herein darf. und das ist genau das, wass du brauchst damit der ping funktioniert (die pix behandelt icmp ja nicht stateful).

sinnvollerweise würde ich am outside interface nur echo-replies hereinlassen.

wenn du noch fragen hast, dann melde dich einfach. :)

lg

martin

hallo,

mit welchem client greifst du denn auf den server zu? welche firewall ist denn dazwischen? greifst du von "aussen" auf den server zu, oder probierst du es aus dem internen lan? machst du passive oder aktiv ftp?

lg

Martin

hallo,

ein super tool ist netperf (google mal danach). das tool hat einen server und client teil. man startet das ding einfach und kann mit einigen parametern sehr genau alles testen.

lg

martin

ps: das ding gibt es für win32 und auch linux.

Hallo,

Meine Erfahrung hat gezeigt, dass man Duplex-Settings immer fix vergeben sollte (ausser bei GBIT-Interfaces). Stell doch mal diese fix ein und schaue dann wie es sich verhält.

lg

Martin

hallo,

es gibt auch die möglichkeit, bestimmte syslog-meldungen zu ignorieren. die pix schreibt dann diese meldung einfach nicht raus. ich glaub da muss man nur die syslog-nummer/id angeben, die man ignorieren will.

lg

martin

Hallo!

Also Cisco sagt das dazu:

Log Message %PIX-4-402103: identity doesn't match negotiated identity

Explanation Unencapsulated IPSec packet does not match the negotiated identity. The peer is sending other traffic through this SA. It may be due to an SA selection error by the peer. This may be a hostile event.

Aber wenn die Verbindung passt und stabil ist, dann vergiss es.

VPN-Verbindungen zw. "fremden" Herstellern ist immer spannend und nicht immer komplett logisch.

lg

martin

Hallo!

Also auf der PIX hast Du immer verschiedene Security-Level.

Inside ist, soweit man das nicht umdreht, IMMER der höchste Level, alles andere ist dann darunter.

der Static lautet grundsätzlich so:

static (höhererLevel,niedrigererLevel), intIP natIp etc.

Warum gehst Du nicht auf die aktuelle Version zb. 6.3(5) (IOS7 gibt es auch so). Alles unter 6.3(x) würde ich nicht mehr einsetzen!! Da gibt es gewaltige Security-Löcher.

Bzw. was willst Du denn mit dem einen Static überhaupt anfangen? Soweit ich statics verwenden, so kann man die schon drehen und wenden wie man es braucht (zumindest ab 6.2x)

Weiters nehme ich an, dass noch conduits verwendet werden. Auch das solltest Du dann auf access-lists umstellen!!!!!

lg

martin

Hallo!

Du kannst per Design nicht das andere Interface der Pix pingen. Das geht einfach nicht.

Man kann immer NUR das direkte Interface pingen.

Wenn Du also hinter dem Inside-LAN hängst, kannst Du NUR das Inside-Interface der Pix pingen.

Wenn Du Durch die PIX durch pingen willst (Internet, etc.), dann musst Du das so machen.

Prinzipiell ist das Sicherheitskonzept der PIX so:

Inside = Höhere Sicherheitsstufe

Outside= Niedrigste Sicherheitsstufe

Alles darf grundsätzlich von der höheren zur niedrigeren Stufe durch. Da brauchst Du grundsätzlich KEINE Access-list machen (ist aber absolut nicht zu empfehlen).

Was Du schon machen musst, ist irgend eine Übersetzung der privaten IPs in pupIPs bzw. eine Übersetzung der privaten IPs in die externe IP der Firewall. Nur dann kann der Datenverkehr im Internet geroutet werden und Du kannst surfen.

Wie man nattet hängt wiederum von Deinen Bedürfnissen ab. Da gibt es auf der PIX wieder mehrer Möglichkeiten:

1) static

2) Nat

3) Pat

Wenn Du am Inside-Interface keine Access-liste gemacht hast, dann kann JEDER Traffic raus (da ja das Inside-Interface die höhere Sicherheitsstufe hat). Damit sollte auch icmp durchgehen.

Wenn Du eine Access-Liste am Inside-Interface gemacht hast, dann musst Du auch icmp dafür freischalten.

Ich glaube, dass Dein Problem ist, dass Du einfach überhaupt nicht ins Internet raus kommst, richtig?

Weiters ist mir in Deiner Konfig aufgefallen, dass Du zwar access-listen konfiguriert hast, diese aber auf kein Interface gebunden sind (access-group). Somit greifen Deine Access-listen absolut nicht.

Ich würde vorschlagen, dass Du mal mit dem PDM (=WebGUI) den Wizard durchmachst. Der richtet dabei automatisch ein NAT ein. Somit solltest Du mal Internetsurfen und auch pingen können. Die Feinheiten macht man dann am besten über die Kommandozeile (der PDM ist nicht gerade optimal).

Befehle, wo Du die PIX komplett deaktivieren kannst (damit eben einfach alles geht), gibt es in diesem Sinne nicht.

Du musst zumindest das Natting mal einrichten. Um alles mal zu testen, ist dann am Inside-Interface entweder gar keine Access-List nötig oder Du trägst access-list xxx permit ip any any ein...Dann geht auch alles durch die PIX durch.

Ich hoffe Dir ein wenig geholfen zu haben.

lg

Martin

Hallo,

Mm, ok, das kann ich Dir auch nicht genau sagen. Bei der CiscoPIX werden die gängisten Protokolle übersetzt. Aber eine genaue Liste kenne ich leider auch nicht.

lg

Martin

Hallo!

Tippe mal bei Google mal "well known ports" ein. Da bekommst Du eine gesamte Liste der Ports und der damit verbundenen Protokolle, etc.

Port 80 ist nur http und NICHT https, weil das wäre dann Port 443

110 wäre pop3

53 wäre dns

25 wäre smtp

111 wäre sunrpc

etc.

Beachten musst Du auch noch, dass Du bei den Freischaltungen auch udp, tcp, icmp, ip, etc. angeben musst.

lg

martin

hello,

kein problem.

danke für den link.

lg

martin

Hallo,

Nein das musst Du nicht, da ja am Outside-Interface wieder die ursprünglich QuellIP anliegt. Das NAT passiert ja innerhalb der PIX. Das Retourpaket wird also wieder quasi zurück genattet und verlässt die PIX mit der ursprünglichen QuellIP...

Die PIX kennt ja auf Grund ihrer NAT-Table was da wie zusammengehört.

lg

martin

Hallo!

Du musst sicherstellen, dass die IP:10.168.1.1 wieder zurück zur PIX geroutet wird.

Weil genau diese IP scheint ja im inside-LAN dann eben auf (auf diese wird ja genattet).

Ich habe das ganze gestern im Office nachgestellt und es hat funktioniert.

lg

Martin

Hello!

Das was Du willst ist im Prinzip ein outsideNAT. Die QuellIP, die vom Outside-Interface kommt, wird auf eine andere IP genattet, wenn eben der Traffic an das Inside-Interface weitergeleitet werden soll.

Wenn ich Dich richtig verstanden haben, dann schaut das bei Dir so aus:

Die 192.168.1.1 soll auf die 10.168.1.1 genattet werden ,wenn der Zugriff auf 10.33.22.50 erfolgen soll. Richtig?

Für den Zugriff auf den Server 10.33.22.50 brauchst, sowie so einen static-Eintrag + access-list. Sonst ist dieser prinzipiell gar nicht erreichbar:

static (inside,outside) 10.33.22.50 10.33.22.50 netmask 255.255.255.255 0 0

+ access-list am outside-interface

(ich gehe mal davon aus, dass der server hinten und vorne die selbe ip-adresse hat)

sonst eben:

static (inside,outside) 10.33.22.50 <priv-ip-des-servers> netmask 255.255.255.255 0 0

So und sollte es, wenn ich mich nicht irre, mit einem weitern static möglich sein, dass Du die QuellIP eben auch umbiegst:

static (outside,inside) 10.168.1.1 192.168.1.1

Das wäre eben das outsideNAT. Dabei sollte die 192.168.1.1, die am Outside-Interface ankommt, bei Zugriffen hinter dem Inside-Interface, auf 10.168.1.1 genattet werden.

Auf das Retourrouting muss noch geachtet werden.

Ich denke, dass das so klappen wird. Ich werde das heute mal bei mir nachstellen.

lg

Martin

Hallo!

Kannst Du mal den gewünschten LINK hier posten, dann kann man das Problem vielleicht nachstellen (hänge auch hinter einer von mir administrierten PIX).

Aber wie schon gesagt, wenn du das fixup für http deaktiviert hast, dann kann der 500er fehler nur vom server selbst kommen.

lg

martin

Hallo!

Mit den statics kann man so ziemlich alles in alle Richtungen naten. Das ging schon immer mit der Pix!!!!!! Dafür brauchst Du nicht das IOS7!!!!

Mit dem static kann man nicht nur von inside nach outside umsetzten.

Es kommt nur auf die Reihenfolge beim Static-Befehl an.

Grundsätzlich lautet die Syntax static (IntHöherePrio,IntniedrigerePrio) ip1 ip2

Man kann das aber drehen wie man will.

lg

Martin

Hallo!

Wenn das logging entsprechend konfiguriert wurde, kannst du alles sehr genau sehen. weiters empfehle ich dir syslog zu konfigurieren.

Am besten ist, Du besorgst Dir die PIX-Doku (http://www.cisco.com), weil das alles zu erklären, ist viel zu lange.

Als Anhaltspunkt suche mal nach syslog, logging.

lg

martin

Hallo!

Das was Du willst funktioniert nur ab IOS-Version 7.xxx

LG

Martin