Hello,<br><br>The following patch is working for me:<br><br>--- net/ipsec/ipsec_rcv.c.orig Tue Dec 23 13:10:46 2008<br>+++ net/ipsec/ipsec_rcv.c Tue Dec 23 15:29:00 2008<br>@@ -1619,18 +1619,44 @@ int klips26_rcv_encap(struct sk_buff *sk<br>
{<br> struct ipsec_rcv_state nirs, *irs = &nirs;<br> struct iphdr *ipp;<br>+ char name[9];<br>+ struct net_device *ipsecdev = NULL, *prvdev = NULL;<br>+ struct ipsecpriv *prv = NULL;<br>+ int i;<br>
<br> /* Don't unlink in the middle of a turnaround */<br> KLIPS_INC_USE;<br> <br> memset(irs, 0, sizeof(*irs));<br> <br>- /* XXX fudge it so that all nat-t stuff comes from ipsec0 */<br>- /* eventually, the SA itself will determine which device<br>
- * it comes from<br>- */ <br>- {<br>- skb->dev = ipsec_get_device(0);<br>+ if(skb->dev) {<br>+ KLIPS_PRINT(debug_rcv,<br>+ "klips_debug:klips26_rcv_encap: "<br>
+ "<<< Info -- ");<br>+ KLIPS_PRINTMORE(debug_rcv, "skb->dev=%s ",<br>+ skb->dev->name ? skb->dev->name : "NULL");<br>+ KLIPS_PRINTMORE(debug_rcv, "\n");<br>
+<br>+ if(skb->dev->name) {<br>+ for(i = 0; i < IPSEC_NUM_IF; i++) {<br>+ sprintf(name, IPSEC_DEV_FORMAT, i);<br>+ ipsecdev = __ipsec_dev_get(name);<br>+ prv = ipsecdev ? (struct ipsecpriv *)(ipsecdev->priv) : NULL;<br>
+ prvdev = prv ? (struct net_device *)(prv->dev) : NULL;<br>+ if(prvdev && !strcmp(prvdev->name, skb->dev->name)) {<br>+ skb->dev = ipsecdev;<br>+ KLIPS_PRINT(debug_rcv && prvdev,<br>
+ "klips_debug:klips26_rcv_encap: "<br>+ "assigning packet ownership to virtual device %s from physical device %s.\n",<br>+ name, prvdev->name);<br>
+ break;<br>+ }<br>+ }<br>+ }<br>+ } else {<br>+ KLIPS_PRINT(debug_rcv,<br>+ "klips_debug:klips26_rcv_encap: "<br>+ "device supplied with skb is NULL\n");<br>
}<br> <br> /* set up for decap loop */<br><br>Does it look right?<br>Below are the details.<br><br>Thanks for your time.<br><br>Regadrs,<br>-hiren<br><br>-------ipsec.conf-------<br>version 2<br>config setup<br> interfaces="ipsec0=eth1 ipsec1=eth2 "<br>
uniqueids=no<br> nat_traversal=yes<br> crlcheckinterval=3600<br><br>conn %default<br> leftupdown=/usr/lib/ipsec/_updown<br> rightupdown=/usr/lib/ipsec/_updown<br><br>conn rw-1<br> auto=add<br>
type=tunnel<br> left=172.16.2.2<br> leftnexthop=172.16.2.1<br> right=%any<br> authby=secret<br> leftsubnet=<a href="http://192.168.88.0/24">192.168.88.0/24</a><br> rightsubnet="vhost:%v4:<a href="http://0.0.0.0/0">0.0.0.0/0</a>"<br>
<br>-------/proc/net/ipsec_tncfg---------<br>ipsec0 -> eth1 mtu=16260(1500) -> 1500<br>ipsec1 -> eth2 mtu=16260(1500) -> 1500<br>ipsec2 -> NULL mtu=0(0) -> 0<br>ipsec3 -> NULL mtu=0(0) -> 0<br><br>
-------ip addr ls---------<br>1: lo: <LOOPBACK,UP> mtu 1500 qdisc noqueue <br> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br> inet <a href="http://127.0.0.1/8">127.0.0.1/8</a> brd 127.255.255.255 scope host lo<br>
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000<br> link/ether 00:0c:29:11:5a:84 brd ff:ff:ff:ff:ff:ff<br> inet <a href="http://192.168.88.13/24">192.168.88.13/24</a> brd 192.168.88.255 scope global eth0<br>
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000<br> link/ether 00:0c:29:11:5a:8e brd ff:ff:ff:ff:ff:ff<br> inet <a href="http://172.16.1.2/24">172.16.1.2/24</a> brd 172.16.1.255 scope global eth1<br>
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000<br> link/ether 00:0c:29:11:5a:98 brd ff:ff:ff:ff:ff:ff<br> inet <a href="http://172.16.2.2/24">172.16.2.2/24</a> brd 172.16.2.255 scope global eth2<br>
9: imq0: <NOARP,UP> mtu 1500 qdisc hfsc qlen 30<br> link/void <br>10: imq1: <NOARP> mtu 1500 qdisc noop qlen 30<br> link/void <br>19: ipsec0: <NOARP,UP> mtu 16260 qdisc pfifo_fast qlen 10<br> link/ether 00:0c:29:11:5a:8e brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://172.16.1.2/24">172.16.1.2/24</a> brd 172.16.1.255 scope global ipsec0<br>20: ipsec1: <NOARP,UP> mtu 16260 qdisc pfifo_fast qlen 10<br> link/ether 00:0c:29:11:5a:98 brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://172.16.2.2/24">172.16.2.2/24</a> brd 172.16.2.255 scope global ipsec1<br>21: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10<br> link/void <br>22: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10<br>
link/void <br><br>--------eroutes--------<br>0 <a href="http://192.168.88.0/24">192.168.88.0/24</a> -> <a href="http://172.16.3.3/32">172.16.3.3/32</a> => <a href="mailto:tun0x100e@172.16.2.1">tun0x100e@172.16.2.1</a><br>
<br>-------tcpdump-------<br>17:31:02.003027 eth2 < 172.16.2.1.4500 > 172.16.2.2.4500: udp 100<br>17:31:02.003027 if20 < 172.16.3.3 > <a href="http://192.168.88.13">192.168.88.13</a>: icmp: echo request<br>17:31:02.003418 if20 > 192.168.88.13 > <a href="http://172.16.3.3">172.16.3.3</a>: icmp: echo reply<br>
17:31:02.003488 eth2 > 172.16.2.2.4500 > 172.16.2.1.4500: udp 100<br><br><br>-------klipsdebug--all---------<br>: klips_debug:klips26_rcv_encap: <<< Info -- skb->dev=eth2 <br>: klips_debug:klips26_rcv_encap: assigning packet ownership to virtual device ipsec1 from physical device eth2. <br>
: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:120 id:27746 frag_off:0 ttl:127 proto:50 (ESP) chk:29415 saddr:172.16.2.1 daddr:172.16.2.2 <br>: klips_debug:ipsec_rcv_decap_once: decap (50) from 172.16.2.1 -> 172.16.2.2 <br>
: klips_debug:ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=46 of <a href="mailto:SA%3Aesp.6c0ad7d8@172.16.2.2">SA:esp.6c0ad7d8@172.16.2.2</a> requested. <br>: klips_debug:ipsec_rcv: <a href="mailto:SA%3Aesp.6c0ad7d8@172.16.2.2">SA:esp.6c0ad7d8@172.16.2.2</a>, src=172.16.2.1 of pkt agrees with expected SA source address policy. <br>
: klips_debug:ipsec_rcv: <a href="mailto:SA%3Aesp.6c0ad7d8@172.16.2.2">SA:esp.6c0ad7d8@172.16.2.2</a> First SA in group. <br>: klips_debug:ipsec_rcv: natt_type=2 tdbp->ips_natt_type=2 : ok <br>: klips_debug:ipsec_rcv: packet from 172.16.2.1 received with seq=12 (iv)=0x2068e8f5abeca063 iplen=100 esplen=88 sa=<a href="mailto:esp.6c0ad7d8@172.16.2.2">esp.6c0ad7d8@172.16.2.2</a> <br>
: klips_debug:ipsec_rcv: encalg = 12, authalg = 2. <br>: klips_debug:ipsec_rcv: authentication successful. <br>: klips_debug:ipsec_rcv: encalg=12 esphlen=24 <br>: klips_debug:ipsec_alg_esp_encrypt: entering with encalg=12, ixt_e=d0b535f0 <br>
: klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=12 ips_key_e=cc14c800 idat=cc34e654 ilen=64 iv=cc34e644, encrypt=0 <br>: klips_debug:ipsec_alg_esp_encrypt: returned ret=64 <br>: klips_debug:ipsec_rcv: padlen=2, contents: 0x<offset>: 0x<value> 0x<value> ... <br>
: klips_debug: 00: 01 02 <br>: klips_debug:ipsec_rcv: packet decrypted from <a href="http://172.16.2.1">172.16.2.1</a>: next_header = 4, padding = 2 <br>: klips_debug:ipsec_rcv: trimming to 60. <br>: klips_debug:ipsec_rcv: after <ESP_AES_HMAC_MD5>, <a href="mailto:SA%3Aesp.6c0ad7d8@172.16.2.2">SA:esp.6c0ad7d8@172.16.2.2</a>: <br>
: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:80 id:27746 frag_off:0 ttl:127 proto:4 chk:29476 saddr:172.16.2.1 daddr:172.16.2.2 <br>: klips_debug:ipsec_rcv: <a href="mailto:SA%3Aesp.6c0ad7d8@172.16.2.2">SA:esp.6c0ad7d8@172.16.2.2</a>, Another IPSEC header to process. <br>
: klips_debug:ipsec_rcv: ESP SA sets skb->nfmark=0x5e0000. <br>: klips_debug:ipsec_rcv: IPIP tunnel stripped. <br>: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:60 id:27746 frag_off:0 ttl:128 proto:1 (ICMP) chk:1686 saddr:172.16.3.3 daddr:192.168.88.13 type:code=8:0 <br>
: klips_debug:ipsec_rcv: IPIP SA sets skb->nfmark=0x5f0000. <br>: klips_debug:ipsec_rcv: netif_rx() called. <br><br><br><div class="gmail_quote">On Mon, Sep 8, 2008 at 7:39 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Mon, 8 Sep 2008, hiren joshi wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That seems like a step in the right direction. Though we should see if we<br>
can determine this properly by looking up the ipsecX interface belonging to<br>
the skb->dev->name ethX interface.<br>
</blockquote>
<br>
The code was just for a PoC.<br>
</blockquote>
<br></div>
I know. Thanks for that.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The comment says that there is some motivation for fudging ipsec0 for<br>
NATed connections.<br>
<br>
/* XXX fudge it so that all nat-t stuff comes from ipsec0 */<br>
/* eventually, the SA itself will determine which device<br>
* it comes from<br>
*/<br>
{<br>
skb->dev = ipsec_get_device(0);<br>
}<br>
<br>
Would it be proper to override this fudging by mapping ipsecX to ethX?<br>
</blockquote>
<br></div>
Yes, that would be the proper fix. I am not sure yet if there was a<br>
reason this needed to be fudged.<br><font color="#888888">
<br>
Paul<br>
</font></blockquote></div><br>