[SOLVED] MAC colision problem

smrtak

Hello,
i have 300 clients with same MAC address in one network and ONE certificate! I

Always can communicate with only one client (the others are disconnected). It is possible to adjust the settings so that they can communicate with everyone at the same time? And doing so, I did not change the MAC address of all clients?
I think that as a reference key is the same certificate is given MAC address, carried it to change the remote IP?

sorry for english.

janjust

how did you end up with 300 clients with the same MAC? is this the same MAC for the tun adapter? how did you end up with that? which OS are these clients running?

connecting 300 devices with the same MAC to any network (VPN or regular) is bound to give you problems - you will need to fix that sooner or later.

smrtak

janjust wrotehow did you end up with 300 clients with the same MAC? is this the same MAC for the tun adapter? how did you end up with that? which OS are these clients running?

connecting 300 devices with the same MAC to any network (VPN or regular) is bound to give you problems - you will need to fix that sooner or later.

I know it's a problem, but unfortunately I can not change back. Clients have been installed over the OS image.
The system is: Windows XP Home and Windows 7.

Not all clients have the same address TUN MAC, there are about 4 versions of image (4 different kinds of MAC).

Mimiko

Are you talking about MAC address or client certificate? If about MAC then you can't have same MAC - it will not work. Remove MAC definition from adapter setting.
If you are talking about client certificate, just add to server's config option "diplicate-cn".

janjust

in a 'tun' style setup you might be able to get away with it by adding to the server config

duplicate-cn

in combination with a username/password login system this might work.

In a 'tap' style setup it is impossible to make this work.

smrtak

As I said, all clients are the same MAC address, and I can not change it.
Therefore we ask for this situation, it is possible to change openvpn so that the problem had solved?
For example, do a patch?

client config:

remote xxxx
port 1194
tls-client
dev tap
proto tcp-client
pull

mute 10
ca xxx
cert xxx
key xxx

comp-lzo
verb 3

#vista patch
route-method exe
route-delay 2

smrtak

and server config:

mode server
tls-server
local xxx
port 1194
dev tap2
proto tcp-server
ifconfig 10.0.3.100 255.255.255.0
ifconfig-pool 10.0.3.1 10.0.3.99 255.255.255.0
duplicate-cn

#push "proto tcp-client"
#push "route-gateway 10.0.3.100"
#push "redirect-gateway def1"
#push "ip-win32 dynamic"
#push "dhcp-option DNS 10.0.3.100"
#push "dhcp-option WINS 10.0.3.100"

#client-to-client

ca xxx
cert xxx
key xxx
dh xxx

log-append xxx
status xxx 10

#route
#push "lladdr 00:ff:a0:b0:12:34"
push "route 10.0.2.0 255.255.255.0 10.0.3.100" 


user nobody
group nogroup
comp-lzo
verb 3
keepalive 10 120


persist-key
persist-tun

#learn-address /etc/openvpn/learn.sh

Mimiko

If all your clients are the same phisical LAN, you can make a OpenVPN client as a router for the others to OpenVPN server.

Otherwise its impossible, because of the nature of TCP/IP protocol. All packets addressed to some IP address is encapsulated and sent via tunnel to MAC addresses - a lower protocol transmission. For example. When some system whant to send a packet to IP 192.168.0.123, the low level driver sends a broadcasting packet asking "Who has the IP 192.168.0.123 and at which MAC address?". After getting the response, the packed is encapsulated and sent to the queried MAC address. What if IP 192.168.0.123 has MAC 01:02:03:04:05:06? So the first system will learn that the data for IP 192.168.0.123 has to be send to MAC 01:02:03:04:05:06. What will be if more systems will have the same MAC with different IP? They all will get the message as if it was addressed for them personally, and will respond back, making a confusion for the first system.

In case of connecting to OpenVPN server. Its like any other DHCP client. Initally client does not have an IP. It sends a special broadcast packet with its MAC asking for an IP. DHCP server gets this packet, assigns an IP, marks the MAC to IP pair in its table and sends back to the original MAC address a packet with assigned IP. Suppose a second client with same MAC connects and sends same packet for an IP. DHCP server learns new packet, sees that this MAC already have an assignef IP amd thinks that client wants an IP renewal - so it change the record of this MAC in its table with new IP and sends back the packet. This packed with the new IP will be received only by the client that made the IPask, because its waits for this. Other client will discard the packet because it didnt ask for an IP. So, on OpenVPN server will be only one record MAC-to-IP, but clients incomming packets also verify for the target IP so will discard the packets not addressed to its IP.

That's why it's impossible without changing MAC addresses. This is not a feature to ask from OpenVPN team, because OpenVPN works on IP level. It must be asked to tun-adapter's driver's developers which holds MAC and IP assigned.

dazo

smrtak wroteAs I said, all clients are the same MAC address, and I can not change it.
Therefore we ask for this situation, it is possible to change openvpn so that the problem had solved?
For example, do a patch?

That's quite a question to ask, if I've understood your question right: You've screwed up your configs and you want OpenVPN patched so that this faulty configuration works?

It is not possible to make any TCP/IP networks work with more NICs (virtual or physical) sharing the same MAC address. So you're screwed if you don't want to change your configs, even if it would would be possible to patch OpenVPN.

So, the solutions you have are:

A) Update config files on all clients, make sure --lladdr is not used. In addition run the remove and create TAP device scripts. Reinstalling OpenVPN, might also be an option which can be automated.

B) Update config files on all clients and switch to TUN mode, plus update the server side to use --mode tun as well.

There are no other chances. And if it would be possible to patch OpenVPN, you would anyway need to reinstall OpenVPN on all your clients, so I don't see how that would make things easier for you.

smrtak

I understand it's low-level problem. Unfortunately I have to update clients.

The problem is how to do it:
1) do have VNC, but the connection is often "disconnected" thanks to the dupl. MAC.
2) Clients should not know that you are connecting.
3) I can not think how to automate it via VNC:)

Can you tell me the easiest way to generate new MAC address of the TAP adapter?

It would be wonderful if we could through the command: PUSH. But I understand that it is not possible, so suffice to command CMD.

Thanks to all for your help:)

smrtak

And of course I have access to admin account windows xp home / win 7, so maybe somehow over RPC?

defsdoor

Sounds dodgy to me - why wouldn't you want the clients to know you were fixing something ?

smrtak

not bad:) Because they are of-sale terminals, it serves only in an emergency for servicing.

The client is quieter, though not knowing what's going on.

janjust

your config shows you're using 'mode tap' ; as I said, this is simply not possible in 'tap' mode. period.
Change the config to 'mode tun' or change the MAC addresses.

defsdoor

I'd limit your VPN to only allow one client in turn to connect (max-clients 1) - this will allow you to connect to it as there is only one device on that one MAC address. Do whatever you need to do to revert your fixed mac address (depending if you have the machines setup for some form of remote access), which will stop that machine from being a problem, and then move on to the next client.

It's going to take some time however, though you should be able to script it.

smrtak

defsdoor wroteI'd limit your VPN to only allow one client in turn to connect (max-clients 1) - this will allow you to connect to it as there is only one device on that one MAC address.

Thanks this helps a lot, and transfer clients to another site and fix the MAC address.
Thanks to all.