1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

tcpdump und ipsec

Dieses Thema im Forum "OpenBSD - Allgemein" wurde erstellt von mark05, 9 April 2018.

  1. mark05

    mark05 Member

    Registriert seit:
    19 November 2003
    Beiträge:
    836
    Ort:
    Bergisch Gladbach
    hi

    ich spiele gerade mit ipsec , gre zwischen juniper und openbsd.

    nun sehe ich folgendens
    bei einem tcpdump -n -i em1 welches da externe interface ist.

    Code:
    11:41:16.647059 esp 1.1.1.2 > 1.1.1.1 spi 0x314a31e0 seq 76 len 152
    11:41:17.643392 1.1.1.1 > 1.1.1.2: gre 192.168.200.254 > 192.168.131.250: icmp: echo request
    11:41:17.644891 esp 1.1.1.2 > 1.1.1.1 spi 0x314a31e0 seq 77 len 152
    11:41:18.642997 1.1.1.1 > 1.1.1.2: gre 192.168.200.254 > 192.168.131.250: icmp: echo request
    11:41:18.644432 esp 1.1.1.2 > 1.1.1.1 spi 0x314a31e0 seq 78 len 152
    11:41:19.642601 1.1.1.1 > 1.1.1.2: gre 192.168.200.254 > 192.168.131.250: icmp: echo request
    11:41:19.644002 esp 1.1.1.2 > 1.1.1.1 spi 0x314a31e0 seq 79 len 152
    11:41:20.641962 1.1.1.1 > 1.1.1.2: gre 192.168.200.254 > 192.168.131.250: icmp: echo request
    11:41:20.643336 esp 1.1.1.2 > 1.1.1.1 spi 0x314a31e0 seq 80 len 152
    
    ist das nun verschluesselt oder nicht ?

    normalerweise dürfte ich doch nicht sehen was innerhalb des ipsec tunnel laeuft.

    holger
     
  2. double-p

    double-p BOFH

    Registriert seit:
    6 September 2003
    Beiträge:
    761
    Ort:
    Buxtehude, Germany
    1.1.1.1 schickt GRE, 1.1.1.2 schickt ESP.
     
  3. mark05

    mark05 Member

    Registriert seit:
    19 November 2003
    Beiträge:
    836
    Ort:
    Bergisch Gladbach
    hi

    wuerde ich auch meinen , heist aber auch das der traffic asyncron ist.
    packete die von 1.1.1.2 kommen sind die "echo reply" zum ping

    hinzukommt das ich auf beiden seiten die tunnel endpunkt in einem vrf habe
    und den tunnel selben in einer via einer 2ten vrf aufbaue.



    1.1.1.2 ist die openbsd kiste
    1.1.1.1 ist die srx
    ipsec tunnel ist einwandfrei aufgebaut.

    holger
     
  4. das.chaos

    das.chaos Duracellhase 2.0

    Registriert seit:
    16 April 2008
    Beiträge:
    432
    Ort:
    Flensburg
    Ob ipsec(4) wirklich funktioniert, kann mittels dem in diesem Artikel beschriebenen Verfahren herausgefunden werden.
     
  5. mark05

    mark05 Member

    Registriert seit:
    19 November 2003
    Beiträge:
    836
    Ort:
    Bergisch Gladbach
    hi

    das problem liegt in der kombiantion juniper srx / gre / ipsec und openbsd / gre / ipsec

    um mit einer srx einen gre tunnel auf zu bauen benoetigt man eine p2p vpn tunnel z.b. 192.168.223.1 <-> 192.168.223.2

    diese ips werden dann als tunnel ips fuer das gre interface genommen.

    falls interesse da ist , kann ich gerne mal die entsprechende config fuer beide seiten mal posten.

    fuer mich ist das der zwischen schritt um egre , welches es seit 6.3 gibt , mit einer juniper srx zu testen

    sprich einer layer 2 ipsec vpn kopplung

    holger
     
  6. das.chaos

    das.chaos Duracellhase 2.0

    Registriert seit:
    16 April 2008
    Beiträge:
    432
    Ort:
    Flensburg
    Mmmhh, wenn die Kiste von Juniper if_bridge(4) und if_gif(4) unterstuezt, dann waere es bspw. "bequem" moeglich beide Stationen [bzw. die zu Koppelnden Netzsegmente] per EtherIP und mit ipsec(4) im Transport Mode abzusichern, wenn jeweils eine Instanz von if_gif(4) Member von if_bridge(4) [auf jeder Station] waere.

    Sowas sollte mit JunOS funktionieren, da ich annehme, dasz das JunOS auf FreeBSD 7.x basiert oder habe ich etwas uebersehen?

    Ich selbst hatte [leider] noch nicht das Vergnuegen, mit einem Router [oder Switch] von Juniper Networks zu arbeiten.
     
  7. mark05

    mark05 Member

    Registriert seit:
    19 November 2003
    Beiträge:
    836
    Ort:
    Bergisch Gladbach
    das.chaos gefällt das.