Re: [Swan] Again: VPN connects but not data traffic through tunnel

2018-10-22 Thread Johannes C. Schulz 
Hello Paul
I tried that, but with no luck. Still the same.

Best regards
Johannes

Am Mo., 22. Okt. 2018 um 12:30 Uhr schrieb Paul Wouters :

> Try without sha-truncbug=yes
>
> Sent from mobile device
>
> On Oct 22, 2018, at 11:09, Johannes C. Schulz 
> wrote:
>
> Good morning Libreswan-folks!
>
> I cannot understand, why my libreswan-VPN does not work correctly. It
> connects but, I get no data through - no ping, no ssh.
>
> Before I start my vpn the routing is like this:
> $ ip ro
> default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
> 169.254.0.0/16 dev enp0s12u2 scope link metric 1000
> 192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 192.168.42.91
> metric 100
> 192.168.42.129 dev enp0s12u2 scope link
>
> for explanation: The client is a roadwarrior, in this case my
> DHCP-server/router is 192.168.42.129 and my local address is 192.168.42.91
>
> Now I start my vpn with following configuration
>
> config setup
> protostack = netkey
> conn Office1
> type=   tunnel
> authby  =   secret
> left = 192.168.42.91
> leftid = @office_vpn_admin
> leftsubnet = 192.168.92.0/24
> leftvti = 192.168.92.234/24
> right =   some-domain.tld
> rightid =   @Office
> keyexchange = ike
> ike = aes256-sha2;dh14
> phase2 = esp
> phase2alg = aes256-sha2;dh14
> sha2_truncbug = yes
> ikelifetime = 4h
> keylife = 8h
> auto = route
> aggrmode = yes
> vti-interface = vti0
> vti-routing = yes
> mark = 5/0x
>
> The connection show up:
>
> 003 "Office1": IKEv1 Aggressive Mode with PSK is vulnerable to dictionary
> attacks and is cracked on large scale by TLA's
> 002 "Office1" #17: initiating Aggressive Mode
> 112 "Office1" #17: STATE_AGGR_I1: initiate
> 010 "Office1" #17: STATE_AGGR_I1: retransmission; will wait 0.5 seconds
> for response
> 010 "Office1" #17: STATE_AGGR_I1: retransmission; will wait 1 seconds for
> response
> 003 "Office1" #17: ignoring unknown Vendor ID payload
> [0048e2270bea8395ed778d343cc2a076]
> 003 "Office1" #17: ignoring unknown Vendor ID payload
> [5cbeb399eb835a7d7a2eb495905db061]
> 003 "Office1" #17: ignoring unknown Vendor ID payload
> [810fa565f8ab14369105d706fbd57279]
> 002 "Office1" #17: Peer ID is ID_FQDN: '@Office'
> 002 "Office1" #17: WARNING: connection Office1 PSK length of 13 bytes is
> too short for sha2_256 PRF in FIPS mode (16 bytes required)
> 002 "Office1" #17: Peer ID is ID_FQDN: '@Office'
> 004 "Office1" #17: STATE_AGGR_I2: sent AI2, ISAKMP SA established
> {auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048}
> 002 "Office1" #18: initiating Quick Mode
> PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
> {using isakmp#17 msgid:d10ecd44
> proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}
> 117 "Office1" #18: STATE_QUICK_I1: initiate
> 010 "Office1" #18: STATE_QUICK_I1: retransmission; will wait 0.5 seconds
> for response
> 002 "Office1" #18: prepare-client output:
> net.ipv4.conf.vti0.disable_policy = 1
> 002 "Office1" #18: prepare-client output: net.ipv4.conf.vti0.rp_filter = 0
> 002 "Office1" #18: prepare-client output: net.ipv4.conf.vti0.forwarding = 1
> 002 "Office1" #18: route-client output: done ip route
> 004 "Office1" #18: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
> mode {ESP/NAT=>0x63b84f91 <0x9be80fa8 xfrm=AES_CBC_256-HMAC_SHA2_256_128
> NATOA=none NATD=xx.yyy.zzz.vv:4500 DPD=passive}
>
> routing then shows
>
> $ ip ro
> default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
> xx.yyy.zzz.vv dev vti0 scope link
> 169.254.0.0/16 dev enp0s12u2 scope link metric 1000
> 192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 192.168.42.91
> metric 100
> 192.168.42.129 dev enp0s12u2 scope link
> 192.168.92.0/24 dev vti0 proto kernel scope link src 192.168.92.234
>
> $ route
> Kernel-IP-Routentabelle
> ZielRouter  Genmask Flags Metric RefUse
> Iface
> default _gateway0.0.0.0 UG10000
> enp0s12u2
> paXXX.dip0. 0.0.0.0 255.255.255.255 UH0  00
> vti0
> link-local  0.0.0.0 255.255.0.0 U 1000   00
> enp0s12u2
> 192.168.42.00.0.0.0     255.255.255.0   U 10000
> enp0s12u2
> _gateway0.0.0.0 255.255.255.255 UH0  00
> enp0s12u2
> 192.168.92.00.0.0.0 255.255.255.0   U 0  00

[Swan] Again: VPN connects but not data traffic through tunnel

2018-10-22 Thread Johannes C. Schulz 
Good morning Libreswan-folks!

I cannot understand, why my libreswan-VPN does not work correctly. It
connects but, I get no data through - no ping, no ssh.

Before I start my vpn the routing is like this:
$ ip ro
default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
169.254.0.0/16 dev enp0s12u2 scope link metric 1000
192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 192.168.42.91
metric 100
192.168.42.129 dev enp0s12u2 scope link

for explanation: The client is a roadwarrior, in this case my
DHCP-server/router is 192.168.42.129 and my local address is 192.168.42.91

Now I start my vpn with following configuration

config setup
protostack = netkey
conn Office1
type=   tunnel
authby  =   secret
left = 192.168.42.91
leftid = @office_vpn_admin
leftsubnet = 192.168.92.0/24
leftvti = 192.168.92.234/24
right =   some-domain.tld
rightid =   @Office
keyexchange = ike
ike = aes256-sha2;dh14
phase2 = esp
phase2alg = aes256-sha2;dh14
sha2_truncbug = yes
ikelifetime = 4h
keylife = 8h
auto = route
aggrmode = yes
vti-interface = vti0
vti-routing = yes
mark = 5/0x

The connection show up:

003 "Office1": IKEv1 Aggressive Mode with PSK is vulnerable to dictionary
attacks and is cracked on large scale by TLA's
002 "Office1" #17: initiating Aggressive Mode
112 "Office1" #17: STATE_AGGR_I1: initiate
010 "Office1" #17: STATE_AGGR_I1: retransmission; will wait 0.5 seconds for
response
010 "Office1" #17: STATE_AGGR_I1: retransmission; will wait 1 seconds for
response
003 "Office1" #17: ignoring unknown Vendor ID payload
[0048e2270bea8395ed778d343cc2a076]
003 "Office1" #17: ignoring unknown Vendor ID payload
[5cbeb399eb835a7d7a2eb495905db061]
003 "Office1" #17: ignoring unknown Vendor ID payload
[810fa565f8ab14369105d706fbd57279]
002 "Office1" #17: Peer ID is ID_FQDN: '@Office'
002 "Office1" #17: WARNING: connection Office1 PSK length of 13 bytes is
too short for sha2_256 PRF in FIPS mode (16 bytes required)
002 "Office1" #17: Peer ID is ID_FQDN: '@Office'
004 "Office1" #17: STATE_AGGR_I2: sent AI2, ISAKMP SA established
{auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048}
002 "Office1" #18: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
{using isakmp#17 msgid:d10ecd44
proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}
117 "Office1" #18: STATE_QUICK_I1: initiate
010 "Office1" #18: STATE_QUICK_I1: retransmission; will wait 0.5 seconds
for response
002 "Office1" #18: prepare-client output: net.ipv4.conf.vti0.disable_policy
= 1
002 "Office1" #18: prepare-client output: net.ipv4.conf.vti0.rp_filter = 0
002 "Office1" #18: prepare-client output: net.ipv4.conf.vti0.forwarding = 1
002 "Office1" #18: route-client output: done ip route
004 "Office1" #18: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP/NAT=>0x63b84f91 <0x9be80fa8 xfrm=AES_CBC_256-HMAC_SHA2_256_128
NATOA=none NATD=xx.yyy.zzz.vv:4500 DPD=passive}

routing then shows

$ ip ro
default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
xx.yyy.zzz.vv dev vti0 scope link
169.254.0.0/16 dev enp0s12u2 scope link metric 1000
192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 192.168.42.91
metric 100
192.168.42.129 dev enp0s12u2 scope link
192.168.92.0/24 dev vti0 proto kernel scope link src 192.168.92.234

$ route
Kernel-IP-Routentabelle
ZielRouter  Genmask Flags Metric RefUse
Iface
default _gateway0.0.0.0 UG10000
enp0s12u2
paXXX.dip0. 0.0.0.0 255.255.255.255 UH0  00 vti0
link-local  0.0.0.0 255.255.0.0 U 1000   00
enp0s12u2
192.168.42.00.0.0.0 255.255.255.0   U 10000
enp0s12u2
_gateway0.0.0.0 255.255.255.255 UH0  00
enp0s12u2
192.168.92.00.0.0.0 255.255.255.0   U 0  00 vti0

$ ping 192.168.92.10
PING 192.168.92.10 (192.168.92.10) 56(84) bytes of data.
>From 192.168.92.234 icmp_seq=1 Destination Host Unreachable

Again I ask you for help. I cannot understand why this will not work. Maybe
this is special to ubuntu/debian-distro?

-- 
Best regards
Johannes C. Schulz

„*Programmer - n. [proh-gram-er] an organism that turns caffeine and pizza
into software“*
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] roadwarrior connects but no data

2018-10-05 Thread Johannes C. Schulz 
Hi Paul

Thanks for your answer. But sadly, this did not help.

$ ip route
default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
xx.yyy.zzz.vv dev vti0 scope link
169.254.0.0/16 dev enp0s12u2 scope link metric 1000
192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 192.168.42.91
metric 100

$ route
Kernel-IP-Routentabelle
ZielRouter  Genmask Flags Metric RefUse
Iface
default _gateway0.0.0.0 UG10000
enp0s12u2
.dip0. 0.0.0.0 255.255.255.255 UH0  00 vti0
link-local  0.0.0.0 255.255.0.0 U 1000   00
enp0s12u2
192.168.42.00.0.0.0 255.255.255.0   U 10000
enp0s12u2


192.168.42.x is the clients network
xx.yyy.zzz.vv is internet-ip of remote network behind some domain
192.168.92.x is the remote network I want to access

Whats wrong with my config?

Best regards
Johannes




Am Do., 4. Okt. 2018 um 16:50 Uhr schrieb Paul Wouters :

> On Thu, 4 Oct 2018, Johannes C. Schulz wrote:
>
> > Hello LibreSwan community!It was a long way to get my libreswan
> connecting to a vpn-server (which is actually a dsl-router from bintec).
> The server accepts IPsec IKEv1
> > connection with PSK. I can connect, but there is no traffic through the
> tunnel.
> > The problem must be on roadwarriors-side, because I can connect and
> transfer data through the tunnel if I connect with a windows machine to the
> vpn-server (using
> > ShrewSoft).
> >
> > I wrote this config:
> >
> > config setup
> > protostack  =   netkey
> >
> > conn Office1
> > authby  =   secret
> > right   =   some.domain.tld
> > rightid =   @Office_admin
> > rightnexthop=   %defaultroute
> > left=   192.168.42.91
> > leftsubnet  =   192.168.92.0/24
> > leftvti =   192.168.92.234/24
> > leftid  =   @Office
> > keyexchange =   ike
> > ike =   aes256-sha2;modp2048
> > esp =   aes256-sha2;modp2048
> > ikelifetime =   4h
> > keylife =   8h
> > auto=   add
> > aggrmode=   yes
> > vti-interface = vti0
> > vti-routing =   yes
> > mark=   5/0x
>
> Try adding sha2_truncbug=yes and see if that fixes your issue. The
> router might be doing "broken linux compatibility" mode by default.
>
> > netstat -r -n
> > Kernel-IP-Routentabelle
> > ZielRouter  Genmask Flags   MSS Fenster irtt
> Iface
> > 0.0.0.0 192.168.42.129  0.0.0.0 UG0 0  0
> enp0s12u2
> > xx.yyy.zzz.vv   0.0.0.0 255.255.255.255 UH0 0  0
> vti0
> > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0  0
> enp0s12u2
> > 192.168.42.00.0.0.0 255.255.255.0   U 0 0  0
> enp0s12u2
> > 192.168.92.00.0.0.0 255.255.255.0   U 0 0  0
> vti0
>
> What does "ip route" say. It is important to see if you got the proper
> route into the VTI interface. I assume xx.yyy.zzz.vv is some.domain.tld's
> IP ?
>
> > ping 192.168.92.10
> > PING 192.168.92.10 (192.168.92.10) 56(84) bytes of data.
> > From 192.168.92.234 icmp_seq=1 Destination Host Unreachable
>
> Is this in the remote end? because you defined that to be on your end?
>
> Paul
>


-- 
Viele Grüße
Johannes C. Schulz

„*Programmer - n. [proh-gram-er] an organism that turns caffeine and pizza
into software“*
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan