Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IPSEC Linux <-> Checkpoint firewall

10 views
Skip to first unread message

Heinrich Elsigan

unread,
Jun 19, 2003, 5:56:53 AM6/19/03
to
Hallo Allerseits !

Ich hab versucht eine IPSEC Verbindung (Subnet to Subnet) von
linux FreeSwan 2.0 / kernel 2.4.18 mit einer checkpoint sidewinder
firewall zu machen. (auth= Pre Shared Key (PSK)).

Ich kann den Tunnel zwischen den beiden gateways herstellen, die
authentifizierung
mit Pre Shared Key funktioniert.

ipsec_setup: Starting FreeS/WAN IPsec 2.00...
ipsec_setup: Using /lib/modules/2.4.18-4GB/kernel/net/ipsec/ipsec.o
104 "xxxx" #1: STATE_MAIN_I1: initiate
106 "xxxx" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "xxxx" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "xxxx" #1: STATE_MAIN_I4: ISAKMP SA established
112 "xxxx" #2: STATE_QUICK_I1: initiate
003 "xxxx" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
004 "xxxx" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

Wenn ich vom Subnet hinter dem Linux gw die Sidewinder pinge, gehen
die icmp packete durch das ipsec interface, werden von der Sidewinder
beantwortet, aber bei mir beim empfangen gedroppt.

Hier einmal meine ipsec.conf:

# a.b.c = linux gw, d.e.f = sidewinder
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=all
plutodebug=all
# overridemtu=1430, habe bereite mich mit der Fragmentierung
gespielt ohne erfolg

conn xxx
left=a.b.c.171 # Local vitals
leftsubnet=192.168.100.0/24 #
leftid=a.b.c.171
leftnexthop=a.b.c.169 # correct in many situations
right=d.e.f.2 # Remote vitals
rightsubnet=172.16.0.0/16
rightid=d.e.f.2
rightnexthop=%defaultroute # correct in many situations
type=tunnel
keylife=3600s
auth=esp
keyexchange=ike
pfs=no
authby=secret
auto=add


Auszug aus dem syslog:

21:35:43 www kernel: klips_debug:ipsec_tunnel_start_xmit: After recursive
xforms -- head,tailroom: 32,24
21:35:43 www kernel: klips_debug:ipsec_tunnel_start_xmit: With hard_header,
final head,tailroom: 18,24
21:35:43 www kernel: klips_debug:ipsec_tunnel_start_xmit: ...done, calling
ip_send() on device:eth0
21:35:43 www kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:136 id:52444
frag_off:0 ttl:64 proto:50 chk:3514 saddr:a.b.c.171 daddr:d.e.f.2
21:35:43 www kernel: klips_debug:ipsec_rcv: <<< Info -- skb->dev=eth0
dev=eth0
21:35:43 www kernel: klips_debug:ipsec_rcv: assigning packet ownership to
virtual device ipsec0 from physical device eth0.
21:35:43 www kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:136
id:43560DF frag_off:0 ttl:52 proto:50 chk:64621 saddr:d.e.f.2
daddr:a.b.c.171
21:35:43 www kernel: klips_debug:ipsec_rcv_decap_once: decap (50) from
d.e.f.2 -> a.b.c.171
21:35:43 www kernel: klips_debug:ipsec_sa_getbyid: linked entry in ipsec_sa
table for hash=168 of SA:esp0xe...@a.b.c.171 requested.
21:35:43 www kernel: klips_debug:ipsec_rcv: SA:esp0xe...@a.b.c.171,
src=d.e.f.2 of pkt agrees with expected SA source address policy.
21:35:43 www kernel: klips_debug:ipsec_rcv: SA:esp0xe...@a.b.c.171 First
SA in group.
21:35:43 www kernel: klips_debug:ipsec_rcv: packet from d.e.f.2 received
with seq=13 (iv)=0x8549a22ca7d18852 iplen=136 esplen=104
sa=esp0xe...@a.b.c.171
21:35:43 www kernel: klips_debug:ipsec_rcv: encalg = 3, authalg = 3.
21:35:43 www kernel: klips_debug:ipsec_rcv: auth failed on incoming packet
from d.e.f.2: hash=b6b013f9ea4b4148613205cb auth=eaf8e08953a2af1bbc4f 0ec4,
dropped
21:35:43 www kernel: klips_debug:ipsec_rcv: decap_once failed: -16 21:35:44
www kernel: klips_debug:ipsec_tunnel_hard_header: skb->dev=ipsec0
dev=ipsec0.
21:35:44 www kernel: klips_debug:ipsec_tunnel_hard_header: Revectored
0p00000000->0pc3336248 len=84 type=2048 dev=ipsec0->eth0 dev_addr=...

An einem tcpdump auf dem linux gateway sieht man, ebenfalls genau das
Problem:
03:00:00.266216 if128 > 192.168.100.1 > 172.16.1.1: icmp: echo request (DF)
(ttl 64, id 0)
03:00:00.266672 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2574)
03:00:00.294651 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50763)ssss
03:00:01.266234 if128 > 192.168.100.1 > 172.16.1.1: icmp: echo request (DF)
(ttl 64, id 0)
03:00:01.266667 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2575)
03:00:01.296539 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50764)
03:00:02.266245 if128 > 192.168.100.1 > 172.16.1.1: icmp: echo request (DF)
(ttl 64, id 0)
03:00:02.266660 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2576)
03:00:02.295308 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50767)
03:00:03.266227 if128 > 192.168.100.1 > 172.16.1.1: icmp: echo request (DF)
(ttl 64, id 0)
03:00:03.266625 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2577)
03:00:03.294895 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50768)

Durch einen Tcpdump auf meinen left Next-hop (ebenfalls) linux gateway,
sieht man, dass
hier alles korrekt durchgeht:
03:00:00.265891 eth1 < a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2574)
03:00:00.265934 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 63, id
2574)
03:00:00.293130 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 53, id
50763)
03:00:00.293157 eth1 > d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50763)
03:00:01.265882 eth1 < a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2575)
03:00:01.265916 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 63, id
2575)
03:00:01.295017 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 53, id
50764)
03:00:01.295043 eth1 > d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50764)
03:00:02.265872 eth1 < a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2576)
03:00:02.265919 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 63, id
2576)
03:00:02.293784 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 53, id
50767)
03:00:02.293812 eth1 > d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50767)
03:00:03.265833 eth1 < a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 64, id
2577)
03:00:03.265878 eth0 > a.b.c.171 > d.e.f.2: ip-proto-50 116 (ttl 63, id
2577)
03:00:03.293366 eth0 < d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 53, id
50768)
03:00:03.293394 eth1 > d.e.f.2 > a.b.c.171: ip-proto-50 116 (DF) (ttl 52, id
50768)


Ich habe zwecks Test, anstatt der Sidewinder ein anderes Linux gateway
verwendet
mit der selben Konfiguration (nur anderen IP-Adressen, auf der rigth-side).
Dort ging alles.

Mein Problem:
Ich muss mit der Firma mit der Sidewinder eine IPSEC Verbindung
herstellen,
PPTP wird aus Security Gründen nicht akkzeptiert.
Hat jemand eine Idee, was hier nicht hinhaut oder welche anderen Lösungen es
für
mein Problem gibt, (ohne teurer proprietäre Hardware, wie CISCO PIX, oder
ähnliches zu kaufen.)


mit bestem Dank im Voraus und freundlichen Grüßen

Heinrich Elsigan.


heinrich elsigan

unread,
Jun 20, 2003, 4:12:24 AM6/20/03
to

> Hallo Allerseits !

Für alle die es interessiert, die IPSEC Verbindung Linux <-> Checkpoint
Sidewinder geht,
allerdings habe ich das nur mit super-freeswan-1.99.7.3
(http://www.freeswan.ca/code/super-freeswan/)
zustande gebracht.

l.G.

Heinrich Elsigan.


0 new messages