Ipsec wel op clients werkend niet op server

[PenguinPower]

Ik heb een vpn samen met een vriend van mij. Hij heeft echter een externe printer server die LPD ondersteund. Dus dacht ik, dan maak ik met mijn cups een remote printer aan zodat ik via mijn linux (server) pc bij hem ook kan printen

Helaas lukte dit niet omdat de server niet eens kan pingen terwijl dit wel op de clients lukt

Ik heb het idee dat er iets mis staat in mijn route tabel:

code:

Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     *          255.255.255.0   U     0  0     0 eth0
192.168.0.0     r1-fe1-0-3-sec. 255.255.255.0   UG    0 0     0 ipsec0
217.120.106.0   *          255.255.254.0   U     0  0     0 eth1
217.120.106.0   *          255.255.254.0   U     0  0     0 ipsec0
default    r1-fe1-0-3-sec. 0.0.0.0     UG    0  0     0 eth1

maar het zou ook best kunnen dat ik een redirect lijntje in mij iptables configuratie moet neerzetten om mijn server werkend te krijgen op de vpn

Voor ff alle duidelijkheid zowel cups als vpn draait op server. Op alle clients werkt het perfect, alleen de server dus niet

[igmar]

Op woensdag 05 juni 2002 17:50 schreef PenguinPower het volgende:
Ik heb een vpn samen met een vriend van mij. Hij heeft echter een externe printer server die LPD ondersteund. Dus dacht ik, dan maak ik met mijn cups een remote printer aan zodat ik via mijn linux (server) pc bij hem ook kan printen

Helaas lukte dit niet omdat de server niet eens kan pingen terwijl dit wel op de clients lukt

Ik heb het idee dat er iets mis staat in mijn route tabel:

code:

Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     *          255.255.255.0   U     0  0     0 eth0
192.168.0.0     r1-fe1-0-3-sec. 255.255.255.0   UG    0 0     0 ipsec0
217.120.106.0   *          255.255.254.0   U     0  0     0 eth1
217.120.106.0   *          255.255.254.0   U     0  0     0 ipsec0
default    r1-fe1-0-3-sec. 0.0.0.0     UG    0  0     0 eth1

maar het zou ook best kunnen dat ik een redirect lijntje in mij iptables configuratie moet neerzetten om mijn server werkend te krijgen op de vpn

Voor ff alle duidelijkheid zowel cups als vpn draait op server. Op alle clients werkt het perfect, alleen de server dus niet

Maar even het hele verhaal laten staan, wel handig :

Je zet een tunnel op tussen 2 servers. Normaliter zijn je servers (outside IP's) GEEN onderdeel van die tunnel, terzij je dat apart opzet.

Voor de duidelijkheid :

1) een machine op 192.168.1.x kan een machine op 192.168.0.x pingen ?

2) Kan je vanaf een VPN gateway een machine op het andere netwerk pingen ??

FreeSWAN zet af en toe wat rare routing op, oa het subnet van het outside IP via de ipsec link laten routen.

Beginnen de zaken te werken indien je 'route del -net 217.120.106.0 netmask 255.255.254.0 dev ipsec0' geeft ??

[PenguinPower]

1) een machine op 192.168.1.x kan een machine op 192.168.0.x pingen ?

Ja, en andersom ook

2) Kan je vanaf een VPN gateway een machine op het andere netwerk pingen ??

Nee en dat is nu net het probleem

Beginnen de zaken te werken indien je 'route del -net 217.120.106.0 netmask 255.255.254.0 dev ipsec0' geeft ??

Nej, helaas

Je zet een tunnel op tussen 2 servers. Normaliter zijn je servers (outside IP's) GEEN onderdeel van die tunnel, terzij je dat apart opzet.

vervelend.... dat is juist eigenlijk wel nodig...

toen ik trouwens ifconfig ipsec0 deed zag ik trouwens dat het ip adres van de vpn verbinding hetzelfde is als die van het internet.

[JayTaph]

>vervelend.... dat is juist eigenlijk wel nodig...

Daarvoor heb je nog host-to-host en/of host-to-subnet verbindingen nodig.

Als je op je eigen vpn-systeem naar een 192.168.0.0 adres pingt, dan is je source-adres niet een 192.168.1.0 adres (zoals bij elk ander systeem die als gateway de vpn heeft), maar 217.120.nogwa.

Wat je dus moet doen, zijn de volgende ipsec-verbindingen maken:

192.168.0.0 <==> 192.168.1.0 (subnet to subnet)
192.168.0.0 <==> ip-addres comp (subnet to host)
217.120.nogwa <==> 192.168.1.0 (host to subnet)
217.120.nogwa <==> ip-addres comp (host to host)


Als je deze 4 verbindingen hebt, kun je vanuit elk systeem inclusief de VPN-server een verbinding leggen met elk ander systeem (inclusief de VPN-server aan de andere kant).

[igmar]

Op donderdag 06 juni 2002 09:57 schreef JayTaph het volgende:
>vervelend.... dat is juist eigenlijk wel nodig...

Daarvoor heb je nog host-to-host en/of host-to-subnet verbindingen nodig.

Als je op je eigen vpn-systeem naar een 192.168.0.0 adres pingt, dan is je source-adres niet een 192.168.1.0 adres (zoals bij elk ander systeem die als gateway de vpn heeft), maar 217.120.nogwa.

Wat je dus moet doen, zijn de volgende ipsec-verbindingen maken:

192.168.0.0 <==> 192.168.1.0 (subnet to subnet)
192.168.0.0 <==> ip-addres comp (subnet to host)
217.120.nogwa <==> 192.168.1.0 (host to subnet)
217.120.nogwa <==> ip-addres comp (host to host)


Als je deze 4 verbindingen hebt, kun je vanuit elk systeem inclusief de VPN-server een verbinding leggen met elk ander systeem (inclusief de VPN-server aan de andere kant).

Inderdaad.. Kijk wel na je route tabel nadat de tunnels draaien, ik moet iig met 1.95 nog handmatig entries uit de route tabel knikkeren. (eroute bug probleem oplossing gevolgen )

[PenguinPower]

Op donderdag 06 juni 2002 10:00 schreef igmar het volgende:

[..]

Inderdaad.. Kijk wel na je route tabel nadat de tunnels draaien, ik moet iig met 1.95 nog handmatig entries uit de route tabel knikkeren. (eroute bug probleem oplossing gevolgen )

ik heb 1.97

Maar hoe zit dat dan? moet ik in de ipsec.conf gewoon een nieuwe conn maken?

Edit: Sorry, al gevonden in de man van ipsec.conf

Bedankt igmar en JayTaph !