Android SSL client - random Mac addresses

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
coolname
Posts: 5
Joined: Mon Jun 10, 2019 7:17 am

Android SSL client - random Mac addresses

Post by coolname » Mon Jun 10, 2019 8:01 am

Hi there,

Trying to put together an android SSL client mimicking Softether Windows client - a scaled down version but ran into an issue. The server keeps complaining about this:

Although the virtual hub has attempt to assign a new MAC address "40-00-40-11-B1-0B" was made, 3 MAC addresses have already been assigned for this service. According to the security policy, this session is denied bridges and is therefore allowed to hold no more than 3 MAC addresses. The packet has been discarded.

Prior to this, server has already "assigned" 3 Mac addresses as the log indicates with this kind of message: A new MAC address "40-00-40-06-E7-15" has been assigned.


Questions for the experts:

1. Why is softether server assigning Mac addresses to clients? Why not just use the Mac address from the client in the packets like the Windows client? Is there a way to tweak the server configuration/code to change this behavior to avoid the above mentioned error message so the data packets are accepted?

2. Since android VpnService API requires a VPN IP address in order to call its establish() to create a tun interface, while normally on linux, I must create a network interface first in order to get an IP address from a DHCP server, how to address the chicken and egg issue on android? Does it make sense to modify the server to maintain a lookup table of VPN IP addresses, and their sessions and send the IP address to android client during the initial handshake? Are there better solutions?

3. Another issue is that my android client sends data blocks to server, server accepts them, but the server doesn't send any real data blocks to client except for keepalive. There is no data from server even after the limit of 3 Mac addresses were increased to 3000. What's causing this?

4. After the initial handshake, the connection would usually disconnect in 1 min. But if an "additional" handshake is done, even though the server terminates it immediately, somehow the first connection lasts about 10 min before it's disconnected while there is still keepalive exchanges. Is there a reason for such behavior?

5. Softether has been a target for GFW especially its active probes. Are there any ideas on improving softether server to counter GFW?

6. Should UDP acceleration be turned off to minimize the risk of the server being detected by GFW? What would be the speed impact w/o it?

7. What part of the server needs to be modified in order for the android client to work? Any other obstacles I might run into? Any recommendations?


Thank you in advance for any guidance and experience you can share.
Jim

coolname
Posts: 5
Joined: Mon Jun 10, 2019 7:17 am

Re: Android SSL client - random Mac addresses

Post by coolname » Wed Jun 12, 2019 3:48 pm

Looks like the random Mac addresses are a result of the differences between Tun and Tap. A wrapper to make tun packets look like Tap packets is needed. Anybody has any experience on how to implement it? On client side or server side? Is the OpenVpn clone a good example to model?

coolname
Posts: 5
Joined: Mon Jun 10, 2019 7:17 am

Re: Android SSL client - random Mac addresses

Post by coolname » Wed Jun 12, 2019 11:32 pm

Does Softether server support tun interface (instead of the default tap?) If not, does it make sense to tweak the server code to provide support for a tun vs. changing client or adding a tun to tap wrapper?

Does the softether data blocks - tap ethernet frames - include IP packet headers + data, or just data but w/o IP packet headers?

Any resources on conversion between tun IP packets and tap ethernet frames would be appreciated.

Post Reply