**** BEGIN LOGGING AT Thu Oct 25 03:00:01 2012 Oct 25 12:08:21 hmm, on http://wiki.openwrt.org/doc/howto/vpn.ipsec.firewall is said to create an extra zone for the IPsec vpn. can anyone tell me how the IPsec traffic is matched to that zone ? Oct 25 12:09:30 hi, do you know if dev.openwrt.org is alive? i'm getting 502 bad gateway errors when trying to load it... Oct 25 12:10:38 tonikasch: it is alive Oct 25 12:10:43 but the webserver is dead Oct 25 12:10:44 getting 502 here too Oct 25 12:10:49 fcgi is crapping up Oct 25 12:11:26 :$ Oct 25 12:12:20 ok, thx Oct 25 12:24:41 ah, found it Oct 25 12:31:36 yeah? pls document it ;-P Oct 25 12:32:41 tonikasch: it's on the same page Oct 25 12:32:48 they match the zone based on source network Oct 25 12:32:58 and that rule is probably added by the ipsec-tools init script Oct 25 12:33:00 not sure Oct 25 12:33:07 I can't use ipsec-tools however Oct 25 12:33:14 it doesn't do IKEv2, strongswan does Oct 25 12:33:57 I still can't get the OpenWrt device to NAT the packets coming in from the IPsec tunnel out to WAN though Oct 25 12:39:12 iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE Oct 25 12:39:16 stintel: check if you have correct policies in 'ip xfrm policy' Oct 25 12:39:17 do you have the two interface in diff zones? Oct 25 12:39:20 and it still doesn't masquerade them Oct 25 12:39:57 voyo: I see the packet going out the wan interface, but with the 172.22.0.1 IP Oct 25 12:40:09 that should not be possible after adding the rule I just pasted Oct 25 12:40:15 it makes no sense whatsoever Oct 25 12:40:15 wait, are you doing with uci or manually? Oct 25 12:40:28 Alam_Squeeze: manually Oct 25 12:42:00 stintel: what is 172.22.. ? you are suggesting that your MASQERADE line is not working ? check ip rules and this xfrm policies Oct 25 12:42:14 voyo: 172.22.0.1 is the virtual IP of the IPsec client Oct 25 12:43:00 voyo: I don't see your point. the packet goes through the IPsec tunnel, out of the WAN interface of the openwrt device. so the ipsec policies are OK otherwise that traffic wouldn't go out the WAN iface Oct 25 12:43:26 but it goes out with the 172.22.0.1 IP even though I have that masquerade rule Oct 25 12:44:39 seriously, this is insane Oct 25 12:45:28 it is added as local IP on your router? is your case is to NAT of locally generated traffic ? Oct 25 12:45:59 voyo: 172.22.0.1 is the virtual IP of the client. Oct 25 12:46:20 ah ok Oct 25 12:46:22 http://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp Oct 25 12:46:24 this one ;) Oct 25 12:47:09 it works fine to connect to other zones on the openwrt device, because I don't need NAT to those zones Oct 25 12:47:37 so everything is OK, except iptables POSTROUTING skips packets coming from inside an IPsec tunnel or wtf ? Oct 25 12:48:58 tried -j MASQUERADE, also tried SNAT Oct 25 12:50:02 stintel: I have similar experience of myself, usualy it was some problems within "ip rul" or "ip x pol" Oct 25 12:50:07 if only this retarded corporate network wouldn't suck so hard Oct 25 12:50:51 voyo: well, strongswan adds the routing rules for every client in table 220 Oct 25 12:51:29 maybe I should just add the 172.20.0.0/24 in the main table Oct 25 12:53:07 and this is horribly annoying to test, because I need to switch from leftsubnet=0.0.0.0/0 to something internally; then down & up the client to be able to access internet again Oct 25 12:53:23 fucking IPsec :@ Oct 25 12:53:35 stintel: can;t help more without full view of your config. but again - check what is in 'ip x pol', if this all is what you want. Oct 25 12:54:46 voyo: hold on I am trying to pastebin it Oct 25 12:55:51 voyo: http://pastebin.com/W8mHN9eW Oct 25 12:56:58 voyo: as I understand, since the packet already goes out the wan interface, I don't think anything can be wrong with ip x pol ?\ Oct 25 12:57:36 hold on, reading your paste. Oct 25 12:57:48 and your intention is to NAT what traffic ? Oct 25 12:58:05 voyo: 172.22.0.1 -> wan Oct 25 12:58:14 (out eth1) Oct 25 12:58:52 try to remove 1st rule from mentioned 'ip x pol' and check Oct 25 12:59:31 voyo: that rule is inserted by strongswan... Oct 25 12:59:39 yes I know Oct 25 13:00:05 but explain my why you would do that ? Oct 25 13:00:58 I really don't see the point. if I see my packet from the ipsec client, going out the WAN of the openwrt router, the ipsec config should be OK afaik? Oct 25 13:01:11 these policies are taking precedense before iptables rules are applied Oct 25 13:03:25 ok, so I will try what you say. only thing that will do, imo, is stop the packet coming from my client to being forwarded anywhere at all. Oct 25 13:04:13 so I will no longer see it going out WAN, nor will I be able to connect from client to the internal zones on rthe openwrt device Oct 25 13:04:23 that, or I really don't get anything about IPsec on Linux at all Oct 25 13:06:21 exactly Oct 25 13:06:26 1 * * * Oct 25 13:11:09 dev.openwrt.org --> 502 bad gateway Oct 25 13:11:19 the whole dayy long :-( Oct 25 13:18:57 hah Oct 25 13:19:01 added a log rule Oct 25 13:19:14 in the POSTROUTING table, gives this output: [80032.312796] le-wtfIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=68 TOS=0x00 PREC=0x00 TTL=64 ID=47782 DF PROTO=UDP SPT=38985 DPT=53 LEN=48 Oct 25 13:19:27 ehr, no Oct 25 13:19:36 that's coincidence Oct 25 13:20:12 so the packet isn't picked up by postrouting at all Oct 25 13:21:50 all of this would be so much easier if IPsec used a virtual interface Oct 25 13:33:51 stintel: I told you that. just play with rules in xfrm.. Oct 25 14:59:39 [florian]: did you get to test anything? Oct 25 15:00:17 <[florian]> DonkeyHotei: not yet Oct 25 15:02:28 [florian]: maybe i could test something? Oct 25 15:03:10 <[florian]> DonkeyHotei: sure, let me send you my patches when I am back home Oct 25 15:06:02 k Oct 25 15:24:56 * tonikasch has to part now, see you later Oct 25 19:38:21 blogic: cond_resched() with a spinlock held doesn't look so cunning Oct 25 19:40:45 true Oct 25 19:40:55 do you have that pastebin link handy ? Oct 25 19:40:59 i lost it ;) Oct 25 21:50:06 https://dev.openwrt.org/attachment/ticket/12361/ Oct 26 01:49:45 [florian]: the gpio's are spectacularly wrong **** ENDING LOGGING AT Fri Oct 26 03:00:01 2012