SSTP pushing 1.0.0.1 via IPCP

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
colemar
Posts: 4
Joined: Thu Dec 19, 2013 8:36 am

SSTP pushing 1.0.0.1 via IPCP

Post by colemar » Fri Nov 21, 2014 10:52 am

I am using sstp-client (https://sourceforge.net/p/sstp-client/) on Linux for connecting via SSTP to SoftEther VPN server with SecureNAT on Ubuntu 14.04.1 LTS x64.
I noticed that the SoftEther VPN server is pushing the address 1.0.0.1 via IPCP, causing the client pppd to set up a route for it:
---
# route -n4
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
1.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 10.220.21.1 255.0.0.0 UG 0 0 0 eth0
10.220.21.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo

# grep IPCP /var/log/syslog
Nov 21 08:28:58 lub pppd[3533]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 21 08:28:58 lub pppd[3533]: rcvd [IPCP ConfReq id=0x2 <addr 1.0.0.1>]
Nov 21 08:28:58 lub pppd[3533]: sent [IPCP ConfAck id=0x2 <addr 1.0.0.1>]
Nov 21 08:28:58 lub pppd[3533]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <ms-dns2 0.0.0.0>]
Nov 21 08:28:58 lub pppd[3533]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0>]
Nov 21 08:28:58 lub pppd[3533]: rcvd [IPCP ConfNak id=0x2 <addr 192.168.30.11> <ms-dns1 192.168.30.1>]
Nov 21 08:28:58 lub pppd[3533]: sent [IPCP ConfReq id=0x3 <addr 192.168.30.11> <ms-dns1 192.168.30.1>]
Nov 21 08:28:58 lub pppd[3533]: rcvd [IPCP ConfAck id=0x3 <addr 192.168.30.11> <ms-dns1 192.168.30.1>]

# ifconfig -a
eth0 Link encap:Ethernet HWaddr 08:00:27:75:fb:7c
inet addr:10.220.21.73 Bcast:10.220.21.255 Mask:255.255.255.0
[...]
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.30.11 P-t-P:1.0.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1219 (1.2 KB) TX bytes:450 (450.0 B)
---

The Virtual Host's Network Interface IP address is 192.168.30.1, therefore I do not understand why the vpn server pushes 1.0.0.1 instead of 192.168.30.1.
Since the pppd configuration has the options [defaultroute] and [replacedefaultroute], there is a default route to interface ppp0 in place, therefore missing the route for 192.168.30.1 is USUALLY not a problem.
However if we have a route for 192.168.0.0/16 (which is PRIVATE-ADDRESS-CBLK-RFC1918-IANA-RESERVED) in place (because there are such hosts on the LAN), then having a more specific route for 192.168.30.1 to ppp0 is mandatory (also because 192.168.30.1 is the DNS server address pushed by the VPN server to the client).
Of course I can myself force the route using a command like [route add -net 192.168.30.1/32 dev ppp0], still I believe that the VPN server should push it through IPCP.

The following are the SoftEther VPN server details:
---
Operating system: Ubuntu 14.04.1 LTS x64

# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:22:4d:ae:32:77
inet addr:37.187.108.xxx Bcast:37.187.108.255 Mask:255.255.255.0
inet6 addr: 2001:41d0:a:3cdd::1/128 Scope:Global
inet6 addr: fe80::222:4dff:feae:3277/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1871933999 errors:0 dropped:58475 overruns:0 frame:0
TX packets:2974433761 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:228787493834 (228.7 GB) TX bytes:4273684651964 (4.2 TB)
Interrupt:16 Memory:80400000-80420000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:3086785 errors:0 dropped:0 overruns:0 frame:0
TX packets:3086785 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10123282729 (10.1 GB) TX bytes:10123282729 (10.1 GB)

# uname -a
Linux colm.tk 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

SoftEther VPN Version 4.11 Build 9506

Using Server component on above linux server.

There is no NAT or Firewall between VPN server and the Internet.

Using SecureNAT.
---

vpn_server.config is attached
You do not have the required permissions to view the files attached to this post.

dajhorn
Posts: 137
Joined: Mon Mar 24, 2014 3:59 am

Re: SSTP pushing 1.0.0.1 via IPCP

Post by dajhorn » Fri Nov 21, 2014 4:08 pm

This is a quirk in the SoftEther PPP code at:

* https://github.com/SoftEtherVPN/SoftEth ... PPP.c#L304

I guess that it happens as a consequence of how SoftEther uses IP addresses without actually binding them to interfaces that are visible on the host. If this behavior is problematic, then you should create a Github issue ticket for it.

cnfer
Posts: 8
Joined: Fri Nov 14, 2014 11:43 pm

Re: SSTP pushing 1.0.0.1 via IPCP

Post by cnfer » Fri Nov 21, 2014 10:04 pm

I have the same problem with l2tp atm. xl2tpd / pppd don't show me the actual ip of the gateway, just 1.0.0.1

I am uncertain how to get the actual gateway ip programatically.

colemar
Posts: 4
Joined: Thu Dec 19, 2013 8:36 am

Re: SSTP pushing 1.0.0.1 via IPCP

Post by colemar » Sat Nov 22, 2014 4:29 am

@cnfer
I believe it is impossible to programmatically determine the remote point IP address.
You only know the IP address assigned to the client, for example w.x.y.z, and a FAKE remote IP address (1.0.0.1). The real remote IP address is likely w.x.y.1, but it coul be literally any valid IP address.

colemar
Posts: 4
Joined: Thu Dec 19, 2013 8:36 am

Re: SSTP pushing 1.0.0.1 via IPCP

Post by colemar » Sat Nov 22, 2014 4:33 am

dajhorn wrote:
> This is a quirk in the SoftEther PPP code at:
>
> *
> https://github.com/SoftEtherVPN/SoftEth ... PPP.c#L304
>
> I guess that it happens as a consequence of how SoftEther uses IP addresses
> without actually binding them to interfaces that are visible on the host.
> If this behavior is problematic, then you should create a Github issue
> ticket for it.

Many thanks for pointing out the culprit.
I created a new issue ticket on Github.

The fact that the VPN server uses a built-in TCP/IP stack with invisible interfaces is sometimes a nuisance to the extent that it renders debug much more difficult.

Post Reply