<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4630.0">
<TITLE>Switch discarding packets</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">Hi all!</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">My setup:</FONT>
</P>

<P><FONT SIZE=2 FACE="Courier New">Client ------------------ OpenSwan ------ network A ------ |</FONT>

<BR><FONT SIZE=2 FACE="Courier New">(config as roadwarrior) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; firewall ---- Internet</FONT>

<BR><FONT SIZE=2 FACE="Courier New">IP in network A &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |---------- network B ------ |</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">The clients, that have a.a.a.a addresses belonging to network A, are WinXP using SafeNet 8.x</FONT>

<BR><FONT SIZE=2 FACE="Arial">Network A is a DMZ, and network B is an internal network (not the main internal one, think of it as an internal-ish DMZ).</FONT></P>

<P><FONT SIZE=2 FACE="Arial">The OpenSwan box is Debian sarge, kernel 2.6.11-1, OpenSwan 2.3.0-2. It's is doing NAT of packets that must go to network B, and this is the default route to reach the internet.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">The authentication is done using self-signed X.509 certificates, and works like a charm.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">NOTE: some time ago I had the &quot;acquire netlink&quot; problem, and I have the impression that's somehow related to the issue I'll discuss in this email. Don't ask me more details, because I haven't investigated in deep.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">We had a DNS server answering requests on the B network, so queries from the client went to the VPN server using the tunnel, came out of the tunnel, were NATed to a b.b.b.b address, reach the DNS server, and the answer did exactly the same in the opposite direction. It worked OK.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Someone needed the DNS on the A network (the same DNS), so he changed it from listening on a b.b.b.b address to an a.a.a.a address. Suddenly, things stopped working for the VPN clients.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Some coffee and a lot of ethereal captures later, we came to the root of the problem&#8230;</FONT>

<BR><FONT SIZE=2 FACE="Arial">The clients were issuing the request using their IP address (a.a.a.a, in the same subnet of the DNS server), they went to the VPN server using the tunnel, came out of the tunnel TOTALLY UNMODIFIED (same IP and same MAC), and were sent to the DNS server. The DNS server received them, and sent the answer back TO THAT IP AND MAC. Then our &quot;intelligent switch&quot; was discarding the packets, based on the criteria that there was no machine with that MAC address in the network, hehehe.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">A possible solution is to do NAT of packets in the A network as well, but I'm not sure if (and HOW) this can affect VPN traffic if I put a rule NATing all outgoing traffic in the a.a.a.a interface of the VPN server...</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Instead of trying that, we simply put the DNS to listen on both networks, so people who needs it on the A network (non-VPN local people) has it, and VPN clients still have it on the B network.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">If someone sees a gross mistake on my side on the analysis of the problem and/or the solution, feel free to comment on that. I'm still in the learning curve of OpenSwan!</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Miguel</FONT>
</P>
<BR>

<br>***********************************************************************************************************<br>
DISCLAIMER:                                                                                                <br>
This e-mail contains proprietary information, some or all of which may be legally privileged.              <br>
It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, <br>
please notify the author by replying to this e-mail. If you are not the intended recipient you may not use,<br>
disclose, distribute, copy, print or rely on this e-mail.                                                  <br>
***********************************************************************************************************</body>
</HTML>