Android SSL client - random Mac addresses
Posted: 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
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