[Openswan Users] Switch discarding packets

Miguel Dilaj mdilaj at nccglobal.com
Wed Jun 8 10:03:51 CEST 2005


Hi all!

My setup:

Client ------------------ OpenSwan ------ network A ------ |
(config as roadwarrior)		|			        firewall
---- Internet
IP in network A			|---------- network B ------ |


The clients, that have a.a.a.a addresses belonging to network A, are WinXP
using SafeNet 8.x
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).
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.
The authentication is done using self-signed X.509 certificates, and works
like a charm.

NOTE: some time ago I had the "acquire netlink" 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.

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.
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.

Some coffee and a lot of ethereal captures later, we came to the root of the
problem.
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 "intelligent switch" was discarding
the packets, based on the criteria that there was no machine with that MAC
address in the network, hehehe.

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...
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.

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!
Cheers,

Miguel




***********************************************************************************************************
DISCLAIMER:                                                                                                
This e-mail contains proprietary information, some or all of which may be legally privileged.              
It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, 
please notify the author by replying to this e-mail. If you are not the intended recipient you may not use,
disclose, distribute, copy, print or rely on this e-mail.                                                  
***********************************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20050608/6814c650/attachment-0001.htm


More information about the Users mailing list