2.6.9-NAT-VPN - fail?

Pagina: 1
Acties:

  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
Situatie: oude pc draait als NAT/router/firewall op kernel 2.6.7 met een afgeleide van Monmotha's script. Alle clients kunnen via NAT het internet op. De Windows machines maken gebruik van Cisco's VPN software om in te bellen op een bedrijfsnetwerk.

Ik heb de kernel veranderd in 2.6.9. Zelfde config, zelfde modules geladen, zelfde firewall-script. Alle clients hebben nog steeds internet. Maar de Cisco's VPN software slaagt er niet meer in om een verbinding te maken: het inkomende reply van de authentication gateway wordt tegengehouden.
code:
1
2
gentoo TCP Rejected IN=ppp0 OUT= MAC= SRC=<vpn gateway> DST=<mijn IP> LEN=140 TOS=0x00 PREC=0x00 TTL=122 ID=28643
 PROTO=TCP SPT=10000 DPT=1187 WINDOW=32767 RES=0x00 ACK URGP=0



Rebooten naar 2.6.7 en alles is weer OK.
Er is dus ergens iets veranderd in 2.6.9. Maar wat?

[ Voor 18% gewijzigd door AlterEgo op 24-10-2004 12:21 ]


  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
Hetzelfde gebeurt bij kernel 2.6.10-rc1-bk3.

Ik post hieronder het log van de vpn-client (windows).
Volgens mij laat dat zien dat er wel communicatie plaatsvindt met de vpn-gateway, maar op een gegeven moment stopt dat.
Dat moment is vind ik dan in mijn iptables log (hierboven) terug.
Deze blokkade vindt dus niet plaats door het firewall script: als ik alle rules flush, gebeurt precies hetzelfde! Het is kernelversie afhankelijk!

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
Cisco Systems VPN Client Version 4.0.3 (D)
Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.1.2600

1      16:01:50.687  10/25/04  Sev=Info/4   CM/0x63100002
Begin connection process

2      16:01:50.687  10/25/04  Sev=Info/4   CVPND/0xE3400001
Microsoft IPSec Policy Agent service stopped successfully

3      16:01:50.687  10/25/04  Sev=Info/4   CM/0x63100004
Establish secure connection using Ethernet

4      16:01:50.687  10/25/04  Sev=Info/4   CM/0x63100024
Attempt connection with server "<vpn-gateway>"

5      16:01:50.687  10/25/04  Sev=Info/6   CM/0x6310002F
Allocated local TCP port 1150 for TCP connection.

6      16:01:50.796  10/25/04  Sev=Info/4   CM/0x63100029
TCP connection established on port 10000 with server "<vpn-gateway>"

7      16:01:50.937  10/25/04  Sev=Info/4   IPSEC/0x63700008
IPSec driver successfully started

8      16:01:50.937  10/25/04  Sev=Info/4   IPSEC/0x63700014
Deleted all keys

9      16:01:50.937  10/25/04  Sev=Info/6   IPSEC/0x6370002B
Sent 4 packets, 0 were fragmented.

10     16:01:50.937  10/25/04  Sev=Info/6   IPSEC/0x6370001F
TCP SYN sent to <vpn-gateway>, src port 1150, dst port 10000

11     16:01:50.937  10/25/04  Sev=Info/6   IPSEC/0x6370001C
TCP SYN-ACK received from <vpn-gateway>, src port 10000, dst port 1150

12     16:01:50.937  10/25/04  Sev=Info/6   IPSEC/0x63700020
TCP ACK sent to <vpn-gateway>, src port 1150, dst port 10000

13     16:01:50.937  10/25/04  Sev=Info/4   CM/0x63100024
Attempt connection with server "<vpn-gateway>"

14     16:01:50.999  10/25/04  Sev=Info/6   IKE/0x6300003B
Attempting to establish a connection with <vpn-gateway>.

15     16:01:51.030  10/25/04  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Unity)) to <vpn-gateway>

16     16:01:56.405  10/25/04  Sev=Info/4   IKE/0x63000021
Retransmitting last packet!

17     16:01:56.405  10/25/04  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to <vpn-gateway>

18     16:02:01.405  10/25/04  Sev=Info/4   IKE/0x63000021
Retransmitting last packet!

19     16:02:01.405  10/25/04  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to <vpn-gateway>

20     16:02:06.405  10/25/04  Sev=Info/4   IKE/0x63000021
Retransmitting last packet!

[snip]

34     16:02:12.109  10/25/04  Sev=Info/4   IPSEC/0x6370000A
IPSec driver successfully stopped



Bij het gebruik van kernel 2.6.7 ziet het vpn-client log er als volgt uit:
code:
1
2
3
4
5
14     16:28:17.875  10/25/04  Sev=Info/6   IPSEC/0x63700020
TCP ACK sent to <vpn-gateway>, src port 1046, dst port 10000

15     16:28:18.093  10/25/04  Sev=Info/5   IKE/0x6300002F
Received ISAKMP packet: peer = <vpn-gateway>,


Het is die stap 15 die dus verkeerd gaat bij het gebruik van kernel 2.6.9.

Waarom komt dat ISAKMP packet niet goed door?
Suggesties zijn meer dan welkom.

[ Voor 36% gewijzigd door AlterEgo op 25-10-2004 16:37 ]


  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
schop

  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
De fix:

The Cisco Windows VPN client (version 4.0.3) heeft twee transport options voor de vpn connectie:
1) ipsec over TCP: die deed het al jaren prima tòt kernel 2.6.9
2) ipsec over udp (nat/pat): deze doet het wel met kernel 2.6.9 or 2.6.10rc1

Dus heb ik de setting aangepast (8>
Waarom methode 1) niet meer werkt is me nog steeds een raadsel.

[ Voor 7% gewijzigd door AlterEgo op 29-10-2004 20:18 ]


  • BoAC
  • Registratie: Februari 2003
  • Laatst online: 21:55

BoAC

Memento mori

offtopic:
Kijk dat zijn nog eens de topics: self-helping ;)


Ik vind IPSec dermate ingewikkeld dat ik er nog maar niet induik ;)
AlterEgo schreef op 29 oktober 2004 @ 20:17:
De fix:

The Cisco Windows VPN client (version 4.0.3) heeft twee transport options voor de vpn connectie:
1) ipsec over TCP: die deed het al jaren prima tòt kernel 2.6.9
2) ipsec over udp (nat/pat): deze doet het wel met kernel 2.6.9 or 2.6.10rc1

Dus heb ik de setting aangepast (8>
Waarom methode 1) niet meer werkt is me nog steeds een raadsel.
Is het nu een tunnel of echt een nieuwe verbinding over TCP?
In het laatste geval wordt het afgeraden zoals ik laatst heb gelezen:
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

[ Voor 71% gewijzigd door BoAC op 29-10-2004 20:52 ]


  • DiNo!
  • Registratie: Juni 2000
  • Laatst online: 07:27
Ik ondervind zelf ook problemen met de 2.6.9 kernel en clients in het netwerk in combinatie met NAT. Bij het browsen naar websites stopt mijn browser met laden. Ik ben er achter gekomen toen ik het gek vond dat *.fok.nl, nu.nl en slashdot.org niet meer laden.

Met tcpdump ben ik erachtergekomen dat er iets fout gaat in het midden van een TCP connectie en dat linux (de router) plotseling een icmp destination unreachable stuurt naar de site die ik bezoek. Deze icmp word verstuurt vlak nadat de site een fragment stuurt van een pakketje.

Deze theorie zou verklaren dan jouw TCP vpn het niet meer doet.

Ik ben nu kernel 2.6.8 aan het compileren (had het al weggegooid) en ik ga kijken of die wel goed werkt met NAT.

https://github.com/atoomnetmarc/


  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
BoAC schreef op 29 oktober 2004 @ 20:49:
offtopic:
Kijk dat zijn nog eens de topics: self-helping ;)
Ik ben soms te fanatiek, vermoeiend hoor ;)
Is het nu een tunnel of echt een nieuwe verbinding over TCP?
In het laatste geval wordt het afgeraden zoals ik laatst heb gelezen:
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
Het is volgens mij een echte tunnel: een nieuwe connectie volgens de client, maar niet op de router.
DiNo7 schreef op 29 oktober 2004 @ 21:13:
Ik ondervind zelf ook problemen met de 2.6.9 kernel en clients in het netwerk in combinatie met NAT
Ik heb geen problemen met NAT en 2.6.9. NAT werkt prima, alleen die vpn verbinding was niet lief.

[ Voor 24% gewijzigd door AlterEgo op 29-10-2004 21:37 ]


  • DiNo!
  • Registratie: Juni 2000
  • Laatst online: 07:27
AlterEgo schreef op 29 oktober 2004 @ 21:36:
[...]

Ik heb geen problemen met NAT en 2.6.9. NAT werkt prima, alleen die vpn verbinding was niet lief.
Mijn probleem bleek wat anders. Ik heb een bridge draaien en die neemt de laagste MTU aan van alle interfaces die toegevoegd waren. Een bridge (zegt men) kan niet rekening houden met z'n eigen MTU.

Alle interfaces naar MTU 1500 deed wonderen. Alles werkt weer (met 2.6.9).

Dit had dus niks te maken met jouw probleem

https://github.com/atoomnetmarc/

Pagina: 1