iptables, esp

Pagina: 1
Acties:
  • 555 views sinds 30-01-2008
  • Reageer

  • charlie
  • Registratie: Oktober 2000
  • Laatst online: 07-03 11:08
Hoi,

Om van thuis uit te werken via onze kabelverbinding draait er op de laptop van mijn vriendin Check point secure client. Deze maakt gebruik van het ipsec protocol 50 (ESP). Als ik deze pc rechtstreeks op de kabelmodem aansluit werkt de verbinding perfect (behalve dat ik een half uurtje moet wachten totdat de dhcp server het adres van mijn server releast).
Ik zou echter graag deze vpn verbinding via masquerading willen laten werken, zodat ik zelf op mijn pc kan verderwerken.

De esp pakketten worden herkend en accepted in de forward chain, maar komen nooit in de nat table terecht, dus kan ik ze ook niet masqueren :(

Chain FORWARD (policy DROP 1 packets, 192 bytes)
pkts bytes target prot opt in out source destination
2207 400K lanout all -- eth1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0
1900 1586K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 192 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT FORWARD packet died: '


Chain lanout (1 references)
pkts bytes target prot opt in out source destination
1691 322K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
11 1624 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2064
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2200
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1352
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:123
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
490 72800 ACCEPT esp -- * * 192.168.0.107 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `Niet gedekt door lanout :'

Chain POSTROUTING (policy ACCEPT 6 packets, 1113 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE esp -- * eth0 0.0.0.0/0 0.0.0.0/0
187 11577 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0

De authenticatie verloopt perfect, maar ik kan verder niet op het netwerk...

Voor alle duidelijkheid, de rest werkt wel...
Wie heeft hier al ervaring mee?

  • Onno
  • Registratie: Juni 1999
  • Niet online
Op woensdag 18 juli 2001 00:26 schreef Charlie23 het volgende:
De esp pakketten worden herkend en accepted in de forward chain, maar komen nooit in de nat table terecht, dus kan ik ze ook niet masqueren :(
Nee, dat kan ook helemaal niet. NAT werkt in principe alleen voor TCP en UDP, en daarnaast werken sommige ICMP packets ook nog wel. Maar de rest niet.

(NAT doet dingen met poortnummers, en protocollen als ESP hebben helemaal geen poorten)

Verder vereist IPsec volgens mij dat beide hosts het eens zijn over wat source en destination IP zijn, anders kan de boel niet gedecrypt worden. (en dat geldt dus niet voor NAT opstellingen)

  • charlie
  • Registratie: Oktober 2000
  • Laatst online: 07-03 11:08
Eigenlijk zou ik dus een soort dubbele nat moeten doen. Als ik nu aan mijn netwerkkaart van de laptop hetzelfde ip adres geef als aan mijn ethernetkaar aan de kabelmodem, en deze door twee nat boxen laat gaan, zou het eigenlijk wel moeten werken.

Zoiets

Laptop(INETIP)<-> (INETGWIP)[NATBOX1](priv.ip) <->(priv.gwip)[NATBOX2](INETIP)<->(INETGWIP)[[Het internet....]]<->(VPNSERVER)

In theorie zou dit moeten lukken.

(SNAT gebruiken, zonder poortnummers, dus enkel de ipheaders veranderen)

  • hightower
  • Registratie: September 2001
  • Laatst online: 04-04-2024
Op woensdag 18 juli 2001 01:52 schreef Onno het volgende:

[..]

Nee, dat kan ook helemaal niet. NAT werkt in principe alleen voor TCP en UDP, en daarnaast werken sommige ICMP packets ook nog wel. Maar de rest niet.

(NAT doet dingen met poortnummers, en protocollen als ESP hebben helemaal geen poorten)

Verder vereist IPsec volgens mij dat beide hosts het eens zijn over wat source en destination IP zijn, anders kan de boel niet gedecrypt worden. (en dat geldt dus niet voor NAT opstellingen)
Dit is niet helemaal waar. Met AH kun je geen NAT gebruiken. Met ESP kan dat wel, echter moet die support wel in de kernel meegecompileerd worden.

specs: Sun Workstation Server Router Laptop


  • Predator
  • Registratie: Januari 2001
  • Laatst online: 11:55

Predator

Suffers from split brain

Op woensdag 18 juli 2001 01:52 schreef Onno het volgende:

[..]

Nee, dat kan ook helemaal niet. NAT werkt in principe alleen voor TCP en UDP, en daarnaast werken sommige ICMP packets ook nog wel. Maar de rest niet.

(NAT doet dingen met poortnummers, en protocollen als ESP hebben helemaal geen poorten)

Verder vereist IPsec volgens mij dat beide hosts het eens zijn over wat source en destination IP zijn, anders kan de boel niet gedecrypt worden. (en dat geldt dus niet voor NAT opstellingen)
NAT heeft niets met poorten te maken.
NAT past headers aan.
IP heeft ook geen poorten en die header past hij natuurlijk aan anders is er helemaal gaan NAT.
Er zijn ook dingen zoals NAT editor modules die dan bepaalde andere headers aanpassen die anders ook de verkeerde adressen bevatten.

ESP kan je door NAT leiden zoals hightower zei.

Met AH ligt dat heel moeilijk omdat die een checksum waarbij ook stukken van de IP header zitten.
Die klopt dan niet meer en packet wordt weggegooid.

Daar bestaat wel iets voor.
Transparent mapping oid waarbij je dus aan de andere kant van de NAT weer de header aanpast met een originele source adres waarbij die checksum weer klopt.
Maar dat werkt maar in bepaalde p2p gevallen.

Everybody lies | BFD rocks ! | PC-specs