SuperFreeS/WAN installatie op RedHat

[Verwijderd]

Ik wil met SuperFreeS/WAN NAT-T (NAT-traversal) fatsoenlijk aan de praat krijgen. Met de gewone FreeS/WAN kreeg ik nl. een foutmelding in de trant van ' no connection known to peer'.

Hiervoor is er wel een patch (van Mikael Lönnroth), maar deze is alleen voor SuperFreeS/WAN en die wil dus maar niet installeren
Bestaat deze trouwens niet voor FreeS/WAN? Kon hem met geen mogelijkheid vinden.

Gebruikt commando in Source-directory SFS: 'make insert', dan 'make oldmod'.

Foutmeldingen zien eruit als:

make [2]: *** [ipsec_life.o] Error 1
make [1]: *** [mod_net/ipsec] Error 2

make: *** [modules] Error 1

Vraag: Klopt het dus dat FreeS/WAN geen NAT-T ondersteunt?

Iemand die het wel is gelukt, SuperfreeS/WAN op Redhat?

Redhat-versie is 9.0, kernel 2.4.20-8
SuperFreeS/WAN versie 1.99.8

[PolarWolf]

Verwijderd schreef op 03 mei 2004 @ 11:58:
Ik wil met SuperFreeS/WAN NAT-T (NAT-traversal) fatsoenlijk aan de praat krijgen. Met de gewone FreeS/WAN kreeg ik nl. een foutmelding in de trant van ' no connection known to peer'.

Hiervoor is er wel een patch (van Mikael Lönnroth), maar deze is alleen voor SuperFreeS/WAN en die wil dus maar niet installeren
Bestaat deze trouwens niet voor FreeS/WAN? Kon hem met geen mogelijkheid vinden.

Gebruikt commando in Source-directory SFS: 'make insert', dan 'make oldmod'.

Foutmeldingen zien eruit als:

make [2]: *** [ipsec_life.o] Error 1
make [1]: *** [mod_net/ipsec] Error 2

make: *** [modules] Error 1

Vraag: Klopt het dus dat FreeS/WAN geen NAT-T ondersteunt?

Iemand die het wel is gelukt, SuperfreeS/WAN op Redhat?

Redhat-versie is 9.0, kernel 2.4.20-8
SuperFreeS/WAN versie 1.99.8

1) FreeS/WAN is dood, check http://www.openswan.org
2) SuperFreeS/WAN is ook dood, check wederom http://www.openswan.org, dit is de opvolger.
3) Van de foutmeldingen heb je de meest nutteloze in je post opgenomen, de echte errors staan er een paar regels boven.

Mijn advies is om opnieuw te beginnen met een recente versie van OpenSWAN. Deze hebben de NAT-T code geintegreerd. Mocht het daar ook niet mee lukken, post dan voldoende informatie om de fout te kunnen achterhalen.

Overigens is SuperFreeSwan een versie van FreeS/WAN die gepatched is met allerlei functionaliteit die vanwege politieke redenen nooit in de distributie is opgenomen. Waaronder NAT-T, dus.

[Verwijderd]

Die overstap wilde ik eigenlijk vermijden , ik heb immers al zoveel tijd in FreeS/WAN gestoken...

Maar aan de andere kant heb je gelijk als je zegt dat het beter is om over te stappen op Openswan. Alleen vraag ik me af of ik dan niet helemaal opnieuw moet beginnen? Of kan ik gewoon de bestaande confifiles overnemen? Afgezien van NAt-traversal had ik namelijk alles werkend..

[PolarWolf]

Verwijderd schreef op 03 mei 2004 @ 12:55:
Die overstap wilde ik eigenlijk vermijden , ik heb immers al zoveel tijd in FreeS/WAN gestoken...

Maar aan de andere kant heb je gelijk als je zegt dat het beter is om over te stappen op Openswan. Alleen vraag ik me af of ik dan niet helemaal opnieuw moet beginnen? Of kan ik gewoon de bestaande confifiles overnemen? Afgezien van NAt-traversal had ik namelijk alles werkend..

Openswan is een doorontwikkeling van superfreeswan. Dezelfde mensen zitten erachter. Ze hebben echter besloten om volledig los van (het toen nog bestaande) FreeS/WAN verder te gaan op basis van de toen laatste releases (superfreeswan werd elke keer opnieuw tegen FreeS/WAN gegenereerd). Een volledige fork, dus. Overigens wist de initiatiefnemer (Ken Bantoft) toen al dat FreeS/WAN de handdoek in de ring ging gooien, dus het kwam allemaal wel mooi uit.

M.a.w. openswan 1.x is een doorontwikkeling van superfreeswan, wat weer is gebaseerd op freeswan 1.9x, en openswan 2.x is een doorontwikkeling van freeswan 2.0x, wat betekend dat je bestaande configuraties zonder wijzigingen zouden moeten werken.

[Verwijderd]

Hartstikke bedankt voor de info en het advies!
Ik ga nu dus maar eens met OpenSwan aan de slag...

[Verwijderd]

OK Openswan is nu goed geinstalleerd (gelukkig ) en de configuratie zoals hij werkte met FreeS/WAN is overgezet.

Alleen komen er in /var/log/secure dus geen meldingen bij een poging om met de client te connecten.
Bij het starten van Ipsec-service krijg ik de volgende melding:

[root@blackbox misc]# service ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec 1.0.3...
ipsec_setup: Using /lib/modules/2.4.20-8custom/kernel/net/ipsec/ipsec.o
ipsec_setup: WARNING: eth1 has route filtering turned on, KLIPS may not work
ipsec_setup: (/proc/sys/net/ipv4/conf/eth1/rp_filter = `1', should be 0)

rp_filter zorg ervoor dat pakketjes niet via dezelfde interface naar buiten kunnen als waarop ze zijn binnengekomen (dat heb ik tenminste zo begrepen )

Ik dus proberen om de rp_filter uit te zetten maar dat lukt niet

Gebruikte commando's :
echo 0 /proc/sys/net/ipv4/conf/eth1/rp_filter en
[root@blackbox misc]# /proc/sys/net/ipv4/conf/eth1/rp_filter = 0

Bij de tweede krijg ik deze foutmelding:
bash: /proc/sys/net/ipv4/conf/eth1/rp_filter: Permission denied

[lordgandalf]

en deze echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter die zouw moeten werken

[Verwijderd]

Ach ja natuurlijk

Maarre, er gebeurt nog steeds niks bij het maken van een verbinding

Ik krijg wel dit als uitvoer van ipsec verify:

ersion check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) ipsec showhostkey: no default key in "/etc/ipsec.secrets" [FAILED]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for blackbox [NO KEY]
Does the machine have at least one non-private address [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADING

[ Voor 80% gewijzigd door Verwijderd op 05-05-2004 11:47 ]

[PolarWolf]

Verwijderd schreef op 05 mei 2004 @ 11:09:
Ach ja natuurlijk

Maarre, er gebeurt nog steeds niks bij het maken van een verbinding

Ik krijg wel dit als uitvoer van ipsec verify:

ersion check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) ipsec showhostkey: no default key in "/etc/ipsec.secrets" [FAILED]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for blackbox [NO KEY]
Does the machine have at least one non-private address [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADING

Tja, dit zegt niet zoveel, he.

Om een niet werkende verbinding te troubleshooten is wel iets meer informatie nodig, bv:
* Wat voor verbinding probeer je te maken
* Wat voor configuratie gebruik je
* Welke firewall regels zitten er tussen
* Wat zegt syslog (/var/log/auth.log)
* Alles wat verder nog relevant is

Ik neem aan dat je de FreeS/WAN documentatie hebt doorgeworsteld? Daarmee moet je al heel ver kunnen komen.

[Verwijderd]

PolarWolf schreef op 05 mei 2004 @ 12:07:
[...]


Tja, dit zegt niet zoveel, he.

Om een niet werkende verbinding te troubleshooten is wel iets meer informatie nodig, bv:
* Wat voor verbinding probeer je te maken
* Wat voor configuratie gebruik je
* Welke firewall regels zitten er tussen
* Wat zegt syslog (/var/log/auth.log)
* Alles wat verder nog relevant is

Ik neem aan dat je de FreeS/WAN documentatie hebt doorgeworsteld? Daarmee moet je al heel ver kunnen komen.

Mijn ipsec.conf:

# version 2.0

config setup
interfaces="ipsec0=eth1"
klipsdebug=none
plutodebug=none
# uniqueids=yes
# plutoload=%search
# plutostart=%search

conn %default
authby=rsasig
left=194.151.63.5
leftnexthop=194.151.63.1
leftcert=/etc/ipsec.d/certs/certificaat.pem
auto=add
leftprotoport=17/1701
rightprotoport=17/1701
pfs=no
leftrsasigkey=%cert
rightrsasigkey=%cert
# esp=3des-md5-96

conn remotecert
rightcert=/etc/ipsec.d/certs/windows.pem
right=%any

De verbinding die wordt gemaakt is dacht ik een tunnel (tenzij anders geconfigureerd) ?

Om alles uit te sluiten heb ik alle firewall regels verwijderd en de policies van de chains op 'accept' gezet

/var/log/auth.log heb ik niet; kan dat /var/log/messages zijn bij mij? (Redhat)

Het vreemde is dat deze configuratie perfect werkte met de 'oude' FreeS/WAN en dat Openswan hier ook mee zou moeten werken, zie een aantal posts hierboven.

[lordgandalf]

heb je wel keys gemaakt en op de juiste plaats gezet ??

want dit duid erop dat ie geen key kan vinden

Checking for RSA private key (/etc/ipsec.secrets) ipsec showhostkey: no default key in "/etc/ipsec.secrets" [FAILED]

je moet als ik het goed begrijp een RSA private key genereren en in /etc/ipsec.secrets plakken

Mischien dat dat help

[Verwijderd]

Die melding bevalt me inderdaad niet. Maar wat jij zegt kan niet, met gebruikmaking van certificaten moet in ipsec.secrets alleen de bestandsnaam van de key opgenomen zijn en het wachtwoord van het certificaat van de server.
Deze heb ik trouwens van m'n oude werkende configuratie overgenomen.
Iemand die weet wat dit betekent en of dit een probleem veroorzaakt?

Maar ik ben ondertussen ietsje verder nu, het lag dus aan het certificaat van Windows. Had deze wel geinstalleerd maar niet geselecteerd in het configuratietooltje van de VPN-client (stom) .
Was dus verkeerd aan het zoeken. Ik dacht dat de VPN server wel een foutmelding zou genereren in /var/log/secure - niet dus.

Nu antwoordt de server in ieder geval op de client, maar er schijnt iets mis te zijn met een certificaat. Ik word gek!
Wie heeft er een idee?

Deze melding komt uit /var/log/secure:

May 5 12:44:48 blackbox pluto[5747]: packet from 82.73.112.206:500: initial Main Mode message received on 194.151.63.5:500 but no connection has been authorized with policy=RSASIG

UPDATE het ligt dus niet aan de certificaten; met een PSK configuratie krijg ik dezelfde melding...
Snap er niets meer van

[ Voor 8% gewijzigd door Verwijderd op 05-05-2004 15:56 ]

[Verwijderd]

OK het ligt dus zeker aan OpenSwan. Blijkbaar verschill en FreeS/WAN en Openswan meer dan ik hoopte, want nu ik FreeS/WAN 2.05 weer heb gecompileerd werkt alles weer als vanouds. Enige verschil is dat ik nu een standaard kernel heb gebruikt ipv de Redhat kernel.
Ik ga nu dus maar eens Openswan compileren in een standaardkernel (2.4.25)

Ik houd jullie op de hoogte (als er tenminste iemand is )

[PolarWolf]

Verwijderd schreef op 05 mei 2004 @ 15:59:
OK het ligt dus zeker aan OpenSwan. Blijkbaar verschill en FreeS/WAN en Openswan meer dan ik hoopte, want nu ik FreeS/WAN 2.05 weer heb gecompileerd werkt alles weer als vanouds. Enige verschil is dat ik nu een standaard kernel heb gebruikt ipv de Redhat kernel.
Ik ga nu dus maar eens Openswan compileren in een standaardkernel (2.4.25)

Ik houd jullie op de hoogte (als er tenminste iemand is )

Ik zou het verstanding vinden om van jou connectie een aparte te maken, dus een en ander uit %default te halen. Zou wel eens kunnen helpen.
i.e.

code:

conn %default
   authby=rsasig
   pfs=no

conn my_left
   left=194.151.63.5
   leftnexthop=194.151.63.1
   leftcert=/etc/ipsec.d/certs/certificaat.pem
   leftprotoport=17/1701
   leftrsasigkey=%cert

conn remotecert
   also=my_left
   right=%any
   rightcert=/etc/ipsec.d/certs/windows.pem
   rightrsasigkey=%cert
   rightprotoport=17/1701
   authby=rsasig
   auto=add

Heb je trouwens die "protoport" dingen ergens voor nodig? Voor zover ik weet hebben die betrekking op NAT.

Zelf moet ik overigens nog steeds openswan implementeren. FreeS/WAN werkt als een zonnetje. Overigens, openswan 1.x is gebaseerd op FreeS/WAN 1.9x, en openswan 2/x op FreeS/WAN 2.x. Misschien handiger om naar openswan 2.x te gaan in dit geval.

[ Voor 3% gewijzigd door PolarWolf op 05-05-2004 17:48 ]

[Verwijderd]

PolarWolf schreef op 05 mei 2004 @ 17:47:
[...]


Ik zou het verstanding vinden om van jou connectie een aparte te maken, dus een en ander uit %default te halen. Zou wel eens kunnen helpen.
i.e.

Heb je trouwens die "protoport" dingen ergens voor nodig? Voor zover ik weet hebben die betrekking op NAT.

gaan in dit geval.

Die protoport dingen komen uit deze tutorial: http://www.jacco2.dds.nl/networking/freeswan-l2tp.html

Je tip over ipsec.conf zal ik ook proberen.

Ik ga nu dus eerst kijken of ik Openswan (versie 2.x) aan de gang krijg met een standaardkernel voor NAT-T icm Win98

Kwam gisteren overigens nog ergens een stukje tegen van iemand met exact hetzelfde probleem. Het schijnt te maken te hebben met de MSL2TP client van Win98 die NAT-T niet zou ondersteunen (wat ergens anders weer wordt tegengesproken .
Met WindowsXP icm Marcus Muller's IPSEC tool werkte het dus wel bij deze persoon.

Als het dus niet werkt met Openswan 2.x is de tweede stap dus teruggaan naar m'n werkende configuratie (freeswan) icm WindowsXP. Dan is het dus jammer voor Win98. Het liefst zou ik alle Windowsversies werkend willen hebben maar het belangrijkst is natuurlijk WindowsXP

[ Voor 8% gewijzigd door Verwijderd op 06-05-2004 10:01 . Reden: toevoeging ]

[Verwijderd]

Ik heb nu ondertussen een werkende OpenSwan v2.1.2rc3 draaien. Hier zit de NAT-T patch standaard al in.
Echter /var/log/secure geeft de volgende melding:

NAT-Traversal: ESPINUDP(1) not supported by kernel -- NAT-T disabled

Op www.openswan.org/code staat een nat-t patch voor de kernel-source:
openswan-2.1.2rc3.natt.patch.gz
Die ga ik maar eens proberen, ik blijf bezig
Momenteel is hij dus (weer eens) aan het compilen...

[Verwijderd]

#$@#!#$ weer dezelfde melding: 'no suitable connection to peer' zie /var/log/secure

code:

May  7 16:22:48 blackbox pluto[19861]: packet from 82.73.112.206:500: ignoring Vendor ID payload [FRAGMENTATION]
May  7 16:22:48 blackbox pluto[19861]: packet from 82.73.112.206:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
May  7 16:22:48 blackbox pluto[19861]: packet from 82.73.112.206:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
May  7 16:22:48 blackbox pluto[19861]: "remotecert" #1: responding to Main Mode
May  7 16:22:48 blackbox pluto[19861]: "remotecert" #1: transition from state (null) to state STATE_MAIN_R1
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: ignoring Vendor ID payload [47bbe7c993f1fc13...]
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: ignoring Vendor ID payload [3025dbd21062b9e5...]
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: ignoring Vendor ID payload [da8e937880010000]
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: received Vendor ID payload [XAUTH]
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
May  7 16:22:49 blackbox pluto[19861]: | protocol/port in Phase 1 ID Payload is 17/4500. accepted with port_floating NAT-T
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: Peer ID is ID_IPV4_ADDR: '10.1.1.10'
May  7 16:22:49 blackbox pluto[19861]: "remotecert" #1: no suitable connection for peer '10.1.1.10'
May  7 16:22:54 blackbox pluto[19861]: "remotecert" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
May  7 16:22:54 blackbox pluto[19861]: | protocol/port in Phase 1 ID Payload is 17/4500. accepted with port_floating NAT-T
May  7 16:22:54 blackbox pluto[19861]: "remotecert" #1: Peer ID is ID_IPV4_ADDR: '10.1.1.10'
May  7 16:22:54 blackbox pluto[19861]: "remotecert" #1: no suitable connection for peer '10.1.1.10'

Mijn ipsec.conf momenteel:

code:

version 2.0

config setup
        interfaces="ipsec0=eth1"
        klipsdebug=none
        plutodebug=none
    nat_traversal=yes

conn %default
    authby=secret
    auto=add
    pfs=no

conn remotecert
    right=82.73.112.206
    rightsubnet=10.1.1.10/32
    left=194.151.63.5
    leftnexthop=194.151.63.1

Ik hou maar op met Win98, probeer het dit weekend eens met Windows XP... Of iemand moet nog suggesties hebben voor bovenstaande...

[PolarWolf]

Verwijderd schreef op 07 mei 2004 @ 16:36:
#$@#!#$ weer dezelfde melding: 'no suitable connection to peer' zie /var/log/secure

Mijn ipsec.conf momenteel:

code:

version 2.0

config setup
        interfaces="ipsec0=eth1"
        klipsdebug=none
        plutodebug=none
    nat_traversal=yes

conn %default
    authby=secret
    auto=add
    pfs=no

conn remotecert
    right=82.73.112.206
    rightsubnet=10.1.1.10/32
    left=194.151.63.5
    leftnexthop=194.151.63.1

Hmm, NAT-T doe ik verder niet aan, maar volgens mij is de bovenstaande config niet voldoende om dat aan de gang te krijgen.

Dat er geen connectie gevonden kan worden, klopt. Wat je namelijk geconfigureerd hebt is

code:

194.151.63.5 --- 194.151.63.1 ===/ internet /=== (waar is rightnexthop?) --- 82.73.112.206 === 10.1.1.10/32

terwijl er een connectoe binnenkomt die verwacht dat er ergens een ipsec gateway op 10.x.x.x zit. Die is nergens geconfigureerd, en dus zal de ipsec code gaan klagen.
Ik geloof dat je nog iets nodig hebt m.b.t. UDP tunneling ofzo. Ik dacht ook dat hier wel documentatie over te vinden was. Kijk maar eens op de Wiki van openswan, en in de source directory waar de documentatie ook in staat.

http://wiki.openswan.org/index.php/NATTraversal

[Verwijderd]

Volgens mij is het gewoon onmogelijk om L2TP via NAT te laten werken. Er ontstaat gewoon een ipsec tunnel, waarna het dus misgaat.

Nu heb ik een aantal mogelijkheden bedacht, waarvan ik graag zou willen weten of deze kunnen.

- Voor niet-genatte clients L2TP, voor clients achter NAT PPTP.
Is het mogelijk om tegelijktijdig een L2TP en PPTP configuratie te hebben?

- Een 'plain IPSEC' tunnel is gelukt met de tool van Marcus Muller.
Probleem hiermee is dat IPsec alleen maar IP kan transporteren.
Pingen gaat dus wel, een computer zoeken in netwerkomgeving niet.

Is dit probleem op te lossen door het (interne) ipnummer van de client binnen het subnet te laten vallen en zo de tunnel transparant te maken?
Ik ben redelijk bekend met iptables commando's...

Dit zou dan de situatie worden:
Windows-subnet(192.168.0.0) --- ipsec via internet --- linuxserver --- intern netwerk (192.168.0.0

Dus 1 groot subnet via een ipsec tunnel

Heb net gehoord dat het mogelijk moet zijn om een computer te zoeken die zich in een ander subnet bevindt.
Ik dacht dat het aan NetBIOS lag, maar als je een computer op IP-nummer zoekt moet het werken, daar is dan wel een bepaald commando in Linux... ben hier nu mee bezig.
Het bovengenoemde transparant netwerk is dus niet meer noodzakelijk, zou op zich nog steeds willen weten of dat wel mogelijk is?

Als iemand iets beters weet hoor ik het uiteraard graag

[ Voor 29% gewijzigd door Verwijderd op 11-05-2004 12:55 ]