Dear Paul,<br><br>If we do that, we will break the principles of non-standard firewall. The connection between two boxes must be non-ip connection. <br><br>I don't know which function of Openswan source code is run firstly when we start ip service.<br>
<br>LNSon.<br><br><div class="gmail_quote">On Wed, Dec 8, 2010 at 1:14 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, 7 Dec 2010, Le Ngoc Son wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Let me explain more details about what I'm working.<br>
<br>
We deployed a firewall system called non-standard firewall to prevent hop-by-hop attacks. This is called non-standard firewall because it includes two boxes (install Linux)<br>
which connect together using non-ip ethernet connection. The model is below:<br>
<br>
connect to Internet----- External Box ----- Internal Box ---connect to LAN<br>
The connection between External and Internal Box is non-IP ethernet connection.<br>
<br>
We decide to deploy Openswan on this non-standard firewall by installing it on Internal Box. We don't install Openswan on External Box because if the hacker can control the<br>
External, it can read the content of all IPSEC packets. We want to avoid it.<br>
<br>
When we configure Openswan at Internal, the IP address of left/ right VPN gateway is the IP address of External (Public IP to Internet), but the Internal does not have any<br>
interface whose IP is the same with IP address of External. The problem is from that. So we need to modify the path of packets coming to Internal.<br>
<br>
We're going to capture all packets on IKE exchanges and push to queue (using Netfilter and libiq), Openswan will listen on this queue, if there is any packet on the queue,<br>
Openswan will process it. This will bypass routing lookup process.<br>
</blockquote>
<br></div>
Why don't you use a "port forward" encapsulated over the non-ip ethernet<br>
connection. Openswan's left (local) should just be its "external ip",<br>
even if that is going to be NAT'ed (eg by External) If the portforward<br>
sends the packet destined for External to the IP on Internal.<br>
<br>
Though granted, this builds an "ip ethernet" connection. between internal<br>
and external, but then again, so does an IPsec tunnel.<br><font color="#888888">
<br>
Paul<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>================================================<br>Le Ngoc Son,<br>Computer Network and Telecommunication Department,<br>Faculty of Information Technology,<br>Natural Sciences University,<br>
National University of HCM City, Vietnam.<br>Email: <a href="mailto:lnson@fit.hcmuns.edu.vn">lnson@fit.hcmuns.edu.vn</a> , <a href="mailto:lnsonvn@gmail.com">lnsonvn@gmail.com</a><br><br>