On 11/15/06, <b class="gmail_sendername">Peter McGill</b> &lt;<a href="mailto:petermcgill@goco.net">petermcgill@goco.net</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Christian Brechbühler Wrote:<br>&gt; On a hunch I changed leftsubnet to <a href="http://192.168.232.10/32"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.10/32</a> -- and BINGO! IPsec SA established.&nbsp;&nbsp;So Openswan seems happy, although<br>&gt; no packets go through.&nbsp;&nbsp;I suspect now it's a routing/firewalling issue.
</blockquote><div><br>Not sure what happened there, because now we changed it back to <a href="http://192.168.232.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.0/24</a>, and it still works.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With leftsubnet <a href="http://192.168.232.10/32"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.10/32</a>, only that ip address on your end will be able to use the vpn tunnel.<br>If you want your whole subnet to be able to use it, you must change leftsubnet to 
<a href="http://192.168.232.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.0/24</a> and have the cisco admin change<br>your subnet on his end as well.</blockquote><div><br>Well our subnet is <a href="http://10.0.0.0/24"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.0/24</a>, so that doesn't match anyway.&nbsp; The Cisco side instructed us to source-network-addres-translate all packets destinated to them, which we do with this rule:
<br><br>-A POSTROUTING -d <a href="http://10.14.8.0/255.255.255.0"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.0/255.255.255.0</a> -o eth1 -j SNAT --to-source <a href="http://192.168.232.10"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.10</a> <br><br>===============================<br><br>
Anyway, the problem persists that we cannot get any traffic through the tunnel.&nbsp; When I tracepath from the VPN gateway to the &quot;NYC&quot; machine, packets seem to go out to the public internet, not through the tunnel.
<br><br>For comparison, I'm running an unrelated ipsec tunnel from an outside box &quot;lithium&quot; running openswan 2.4.4 to our gateway (mentioned above), which also runs openswan 2.4.4.&nbsp; When I ping or traceroute or ssh from &quot;lithium&quot;, all is fine.&nbsp; In other words, the response packets find their way back to lithium.&nbsp; But when the VPN gateway initiates any activity, the packets seem to get lost.&nbsp; Tcpdump doesn't show anything.
<br><br>BTW, VPN gateway runs 2.6.11-gentoo-r5 (lithium has 2.6.9-1.11_FC2).<br><br>Any help to getting packets that start a connection find their way into the appropriate tunnel would be greatly appreciated.&nbsp; Or suggestions for tcpdump-ing outgoing packets.
<br><br>What other info would you need?&nbsp; Output of route?&nbsp; iptables?&nbsp; ipsec.conf?<br><br>Thanks<br>/Christian<br></div><br></div><br>