[Openswan Users] Problem with ShrewSoft VPN Client in DHCP over IPSec Configuration

[Martin Krellmann]

Okay... tcpdump tells me that the DHCP Offer arrives on the ipsec0
interface. It's target IP is the new IP for the client (10.0.1.1 in my case)
I've set klipsdebug to tunnel and searched the log for the dhcp package (and
found it ;) )

Jun 24 19:33:30 gateway pluto[22134]: "roadwarrior-dhcp"[1] 130.149.146.253
#4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jun 24 19:33:30 gateway pluto[22134]: "roadwarrior-dhcp"[1] 130.149.146.253
#4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jun 24 19:33:30 gateway kernel: 
Jun 24 19:33:30 gateway kernel: 
Jun 24 19:33:30 gateway kernel: ipsec_tunnel_start_xmit:
STARTING<6>klips_debug:ipsec_xmit_strip_hard_header: >>> skb->len=342
hard_header_len:14 02:00:4e:43:50:49:00:0a:e6:26:28:f8:08:00 
Jun 24 19:33:30 gateway kernel: klips_debug:   IP: ihl:20 ver:4 tos:16
tlen:328 id:0 frag_off:0 ttl:128 proto:17 (UDP) chk:60477
saddr:xxx.xxx.xxx.xxx:67 daddr:10.0.1.1:68
Jun 24 19:33:30 gateway kernel: klips_debug:ipsec_xmit_strip_hard_header:
Original head,tailroom: 18,152
Jun 24 19:33:30 gateway kernel: klips_debug:udp port check: fragoff: 0 len:
328>28 
Jun 24 19:33:30 gateway kernel: klips_debug:udp port in packet: port 67 ->
68
Jun 24 19:33:30 gateway kernel: klips_debug:ipsec_xmit_SAlookup: checking
for local udp/500 IKE packet saddr=hhhhhhhh, er=0p00000000, daddr=a000101,
er_dst=0, proto=17 sport=67 dport=68
Jun 24 19:33:30 gateway kernel: klips_debug:ipsec_xmit_encap_bundle: shunt
SA of DROP or no eroute: dropping.
Jun 24 19:33:30 gateway kernel: klips_debug:ipsec_xsm: processing completed
due to IPSEC_XMIT_STOLEN.
Jun 24 19:33:30 gateway kernel: klips_debug:ipsec_tunnel_start_xmit:
encap_bundle failed: 2

As you can see it has been dropped...

There is one eroute for the tunnel:
Jun 24 19:47:00 gateway kernel: klips_debug:ipsec_makeroute: attempting to
allocate 192 bytes to insert eroute for 0.0.0.0/0->130.149.146.253/32, SA:
tun.1003 at 130.149.146.253, PID:23349, skb=0p00000000, ident:NULL->NULL
Jun 24 19:47:00 gateway kernel: klips_debug:ipsec_makeroute:
141a100000000000829592fd1100000000440000 /
141aff0000000000ffffffffff000000ffff0000 
Jun 24 19:47:00 gateway kernel: klips_debug:ipsec_makeroute: calling
rj_addroute now
Jun 24 19:47:00 gateway kernel: klips_debug:ipsec_makeroute: pid=23349
count=         0 lasttime=     0 0.0.0.0/0          -> 130.149.146.253/32 =>
tun.1003 at 130.149.146.253
Jun 24 19:47:00 gateway kernel: klips_debug:ipsec_makeroute: succeeded.

So I guess the problem is related to the DHCP server sending the OFFER to
10.0.1.1 and not to the external IP of the querying client
(130.149.146.253). I'm using no dhcp relay agent because I had no luck with
routing the forwarded request of the relay agent to the DHCP server (both on
the same host; latest ISC relay agent). The package did not reach it for
some reason.

Will an relay agent answer to the request on the original source IP address,
or not? If yes I'll try the whole thing with a relay agent again.

Greets,
Martin.

-----Ursprüngliche Nachricht-----
Von: Paul Wouters [mailto:paul at xelerance.com] 
Gesendet: Montag, 22. Juni 2009 15:53
An: Martin Krellmann
Cc: users at openswan.org
Betreff: Re: AW: AW: [Openswan Users] Problem with ShrewSoft VPN Client in
DHCP over IPSec Configuration

On Mon, 22 Jun 2009, Martin Krellmann wrote:

>>> So I guess it is planned to support %dhcp and %ike options to support
the
>>> client auto configuration directly in feature. But this should not
affect
>>> the routing of DHCP packages, or not?
>>
>> that's right.
>
> So is there any way how I can check if openswan accepts the DHCP Offer,
> crypt it and send it over the tunnel?

tcpdump? with klips you can enable klipsdebug and see if it works or why
it rejected the packet. with netkey there is no debugging facility
whatsover.

Paul