subject:"\[strongSwan\] Cannot ping machines on remote local network"

Re: [strongSwan] Cannot ping machines on remote local network - solved

2017-09-08 Thread Ric S

On Freitag, 8. September 2017 13:07:25 CEST Tobias Brunner wrote:
> Hi Ric,
> 
> > I managed to find the bug, wrong truncation still exists in latest
> > 4.4 kernel:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tr
> > ee/ net/xfrm/xfrm_algo.c?h=v4.4.87
> 
> That's only because you are using the kernel-pfkey plugin on Linux,
> which you should not.  It does not provide an interface to change the
> truncation for SHA-256 from userland so the default is used (all kernels
> use 96 bit due to legacy reasons).  The kernel-netlink plugin will set
> the correct truncation length when installing the SA, so just disable
> the kernel-pfkey plugin and you won't need to patch the kernel.
> 
> Regards,
> Tobias


Hi Tobias,

thanks for the info. Maybe this should be noted somewhere, cause I did not 
find any hint regarding this. Could be a good place to add this:

https://wiki.strongswan.org/projects/strongswan/wiki/FAQ

Cheers Ric

Re: [strongSwan] Cannot ping machines on remote local network - solved

2017-09-08 Thread Tobias Brunner

Hi Ric,

> I managed to find the bug, wrong truncation still exists in latest 
> 4.4 kernel:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/
> net/xfrm/xfrm_algo.c?h=v4.4.87

That's only because you are using the kernel-pfkey plugin on Linux,
which you should not.  It does not provide an interface to change the
truncation for SHA-256 from userland so the default is used (all kernels
use 96 bit due to legacy reasons).  The kernel-netlink plugin will set
the correct truncation length when installing the SA, so just disable
the kernel-pfkey plugin and you won't need to patch the kernel.

Regards,
Tobias

Re: [strongSwan] Cannot ping machines on remote local network - solved

2017-09-08 Thread Ric S

Hi guys, I managed to find the bug, wrong truncation still exists in latest 
4.4 kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/
net/xfrm/xfrm_algo.c?h=v4.4.87

in line 242 I changed:

.icv_truncbits = 96,

to

.icv_truncbits = 128,


Now pings work fine no errors anymore and I can connect to machines in the 
lan.


On Mittwoch, 6. September 2017 15:55:48 CEST Ric S wrote:

> Update, I compiled kernel wih xfrm stats and noticed, the error
> XfrmInStateProtoError, increases by one for each ping, so the issue must be
> in this area, what could be the cause for this:
> 
> cat /proc/net/xfrm_stat
> XfrmInError 0
> XfrmInBufferError   0
> XfrmInHdrError  0
> XfrmInNoStates  0
> XfrmInStateProtoError   13
> XfrmInStateModeError0
> XfrmInStateSeqError 0
> XfrmInStateExpired  0
> XfrmInStateMismatch 0
> XfrmInStateInvalid  0
> XfrmInTmplMismatch  0
> XfrmInNoPols0
> XfrmInPolBlock  0
> XfrmInPolError  0
> XfrmOutError0
> XfrmOutBundleGenError   0
> XfrmOutBundleCheckError 0
> XfrmOutNoStates 0
> XfrmOutStateProtoError  0
> XfrmOutStateModeError   0
> XfrmOutStateSeqError0
> XfrmOutStateExpired 0
> XfrmOutPolBlock 0
> XfrmOutPolDead  0
> XfrmOutPolError 0
> XfrmFwdHdrError 0
> XfrmOutStateInvalid 0
> XfrmAcquireError0
> 
> swanctl --list-sas
> ikev2: #2, ESTABLISHED, IKEv2, ff455cdb92936f01_i b37e2279167e23ed_r*
>   local  'myname.ddns.net' @ 87.168.XXX.XXX[4500]
>   remote 'R6400' @ XX.XX.1.5[50455] [192.168.0.121]
>   AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>   established 41s ago, reauth in 9733s
>   ikev2: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
> HMAC_SHA2_256_128
> installed 37s ago, rekeying in 2798s, expires in 3563s
> in  cc231009,  0 bytes, 0 packets
> out 05998a07,  0 bytes, 0 packets
> local  192.168.0.0/24
> remote 192.168.0.121/32
> 
> Also I gave wrong info before neither Win7 or iOS can surf the internet
> through the tunnel. iOS obviously bypasses the vpn, as I see no outgoing
> connections on the routers wan to a specific adress I contact from iOS.
> So basically the only thing going through is the tunnel connection esp
> traffic
> On Mittwoch, 6. September 2017 00:05:23 CEST Ric S wrote:
> > On Dienstag, 5. September 2017 16:36:30 CEST Noel Kuntze wrote:
> > > Hi,
> > > 
> > > See the article about forwarding[1] that I linked previously.
> > 
> > I have done some more experimenting. It is really strange, right after the
> > connection established I get a few pings through, but they stop after 3 or
> > 4 pings, then maybe one in a few minutes goes through.
> > 
> > Very strange. I also notice, that after a while I cannot esatblish a
> > connection to the router, until I request a new IP. Just like traffic is
> > intercepted by the ISP.
> > 
> > But since the Test is done with a LTE modem, thus want to see next week,
> > if
> > I get the same results on a regular line.
> > 
> > > Kind regards
> > > 
> > > Noel
> > > 
> > > [1]
> > > https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitT
> > > un
> > > n
> > > eling#MTUMSS-issues
> > > 
> > > On 05.09.2017 16:33, Ric S wrote:
> > > > On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
> > > >> Hi,
> > > >> 
> > > >> I just noticed that your NAT rules cause problems if you try to
> > > >> initiate
> > > >> connections to the RW, too. Read and apply the advice from the
> > > >> article
> > > >> about NAT problems[1].
> > > > 
> > > > I added :
> > > > 
> > > > iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j
> > > > ACCEPT
> > > > 
> > > > I noticed when I ping the iPad from lan I now see that packages are
> > > > matching and ping changes
> > > > 
> > > > Chain POSTROUTING (policy ACCEPT 1320 packets, 89681 bytes)
> > > > 
> > > >  pkts bytes target prot opt in out source
> > > >  destination>
> > > >  
> > > > 184 ACCEPT 0--  *  *   0.0.0.0/0
> > > > 0.0.0.0/0   policy match dir out pol ipsec>
> > > > 
> > > > before adding the rule:
> > > > 
> > > > ping R6400
> > > > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > > > From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
> > > > Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=2
> > > > Destination
> > > > Host Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=3
> > > > Destination Host Unreachable
> > > > 
> > > > 
> > > > after adding the rule:
> > > > 
> > > > ping R6400
> > > > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > > > hangs here
> > > > 
> > > > Thus this rule most likely is one

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-06 Thread Ric S

Update, I compiled kernel wih xfrm stats and noticed, the error 
XfrmInStateProtoError, increases by one for each ping, so the issue must be in 
this area, what could be the cause for this:

cat /proc/net/xfrm_stat 
XfrmInError 0
XfrmInBufferError   0
XfrmInHdrError  0
XfrmInNoStates  0
XfrmInStateProtoError   13
XfrmInStateModeError0
XfrmInStateSeqError 0
XfrmInStateExpired  0
XfrmInStateMismatch 0
XfrmInStateInvalid  0
XfrmInTmplMismatch  0
XfrmInNoPols0
XfrmInPolBlock  0
XfrmInPolError  0
XfrmOutError0
XfrmOutBundleGenError   0
XfrmOutBundleCheckError 0
XfrmOutNoStates 0
XfrmOutStateProtoError  0
XfrmOutStateModeError   0
XfrmOutStateSeqError0
XfrmOutStateExpired 0
XfrmOutPolBlock 0
XfrmOutPolDead  0
XfrmOutPolError 0
XfrmFwdHdrError 0
XfrmOutStateInvalid 0
XfrmAcquireError0

swanctl --list-sas
ikev2: #2, ESTABLISHED, IKEv2, ff455cdb92936f01_i b37e2279167e23ed_r*
  local  'myname.ddns.net' @ 87.168.XXX.XXX[4500]
  remote 'R6400' @ XX.XX.1.5[50455] [192.168.0.121]
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 41s ago, reauth in 9733s
  ikev2: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
HMAC_SHA2_256_128
installed 37s ago, rekeying in 2798s, expires in 3563s
in  cc231009,  0 bytes, 0 packets
out 05998a07,  0 bytes, 0 packets
local  192.168.0.0/24
remote 192.168.0.121/32

Also I gave wrong info before neither Win7 or iOS can surf the internet 
through the tunnel. iOS obviously bypasses the vpn, as I see no outgoing 
connections on the routers wan to a specific adress I contact from iOS.
So basically the only thing going through is the tunnel connection esp traffic 

On Mittwoch, 6. September 2017 00:05:23 CEST Ric S wrote:
> On Dienstag, 5. September 2017 16:36:30 CEST Noel Kuntze wrote:
> > Hi,
> > 
> > See the article about forwarding[1] that I linked previously.
> 
> I have done some more experimenting. It is really strange, right after the
> connection established I get a few pings through, but they stop after 3 or 4
> pings, then maybe one in a few minutes goes through.
> 
> Very strange. I also notice, that after a while I cannot esatblish a
> connection to the router, until I request a new IP. Just like traffic is
> intercepted by the ISP.
> 
> But since the Test is done with a LTE modem, thus want to see next week, if
> I get the same results on a regular line.
> 
> > Kind regards
> > 
> > Noel
> > 
> > [1]
> > https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTun
> > n
> > eling#MTUMSS-issues
> > 
> > On 05.09.2017 16:33, Ric S wrote:
> > > On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
> > >> Hi,
> > >> 
> > >> I just noticed that your NAT rules cause problems if you try to
> > >> initiate
> > >> connections to the RW, too. Read and apply the advice from the article
> > >> about NAT problems[1].
> > > 
> > > I added :
> > > 
> > > iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
> > > 
> > > I noticed when I ping the iPad from lan I now see that packages are
> > > matching and ping changes
> > > 
> > > Chain POSTROUTING (policy ACCEPT 1320 packets, 89681 bytes)
> > > 
> > >  pkts bytes target prot opt in out source
> > >  destination>
> > >  
> > > 184 ACCEPT 0--  *  *   0.0.0.0/0
> > > 0.0.0.0/0   policy match dir out pol ipsec>
> > > 
> > > before adding the rule:
> > > 
> > > ping R6400
> > > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > > From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
> > > Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination
> > > Host Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=3
> > > Destination Host Unreachable
> > > 
> > > 
> > > after adding the rule:
> > > 
> > > ping R6400
> > > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > > hangs here
> > > 
> > > Thus this rule most likely is one part of the solution.
> > > 
> > > Now I setup a second client, Win7, unlike iOS surfing the net does not
> > > work, and with wireshark I see incoming TCP Retransmissions messages,
> > > looks like there is an issue with mtu/mss? I also managed to get one
> > > ping
> > > through the tunnel to the a lan machine.
> > > 
> > > What is the best way to specify mtu sizes etc in strongswan?
> > > 
> > >> Kind regards
> > >> 
> > >> Noel
> > >> 
> > >> [1]
> > >> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplit
> > >> Tu
> > >> nn
> > >> eling#General-NAT-problems
> > >> 
> > >> On 05.09.2017 12:32, Ric S wrote:
> > >>> On Dienstag, 5. September 2017 11:28:59

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Ric S

On Dienstag, 5. September 2017 16:36:30 CEST Noel Kuntze wrote:
> Hi,
> 
> See the article about forwarding[1] that I linked previously.

I have done some more experimenting. It is really strange, right after the 
connection established I get a few pings through, but they stop after 3 or 4 
pings, then maybe one in a few minutes goes through.

Very strange. I also notice, that after a while I cannot esatblish a 
connection to the router, until I request a new IP. Just like traffic is 
intercepted by the ISP.

But since the Test is done with a LTE modem, thus want to see next week, if I 
get the same results on a regular line.

> 
> Kind regards
> 
> Noel
> 
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunn
> eling#MTUMSS-issues
> On 05.09.2017 16:33, Ric S wrote:
> > On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
> >> Hi,
> >> 
> >> I just noticed that your NAT rules cause problems if you try to initiate
> >> connections to the RW, too. Read and apply the advice from the article
> >> about NAT problems[1].
> > 
> > I added :
> > 
> > iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
> > 
> > I noticed when I ping the iPad from lan I now see that packages are
> > matching and ping changes
> > 
> > Chain POSTROUTING (policy ACCEPT 1320 packets, 89681 bytes)
> > 
> >  pkts bytes target prot opt in out source  
> >  destination>  
> > 184 ACCEPT 0--  *  *   0.0.0.0/0   
> > 0.0.0.0/0   policy match dir out pol ipsec> 
> > before adding the rule:
> > 
> > ping R6400
> > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
> > Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination
> > Host Unreachable From 62.155.242.107 (62.155.242.107) icmp_seq=3
> > Destination Host Unreachable
> > 
> > 
> > after adding the rule:
> > 
> > ping R6400
> > PING R6400 (192.168.0.121) 56(84) bytes of data.
> > hangs here
> > 
> > Thus this rule most likely is one part of the solution.
> > 
> > Now I setup a second client, Win7, unlike iOS surfing the net does not
> > work, and with wireshark I see incoming TCP Retransmissions messages,
> > looks like there is an issue with mtu/mss? I also managed to get one ping
> > through the tunnel to the a lan machine.
> > 
> > What is the best way to specify mtu sizes etc in strongswan?
> > 
> >> Kind regards
> >> 
> >> Noel
> >> 
> >> [1]
> >> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTu
> >> nn
> >> eling#General-NAT-problems
> >> 
> >> On 05.09.2017 12:32, Ric S wrote:
> >>> On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
>  Hi,
>  
> > ifconfig
>  
>  Please don't use the net-tools. Use iproute2. The net-tools are
>  woefully
>  inadequate for this day and age. They are deprecated since the early
>  2000s.
>  
>  Please provide the output of `ip address`, `ip route show table all`,
>  `ip
>  rule` and `sysctl -A | grep rp_filter`.
>  
>  I suspect that at least the rp_filter needs to be set to 2.
> >>> 
> >>> I just set all interfaces to 2, still no go.
> >>> 
> >>> 
> >>> 
> >>> root@titan:~# ip address
> >>> 1: lo:  mtu 65536 qdisc noqueue qlen 1
> >>> 
> >>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >>> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> inet6 ::1/128 scope host
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> 2: teql0:  mtu 1500 qdisc noop qlen 100
> >>> 
> >>> link/void
> >>> 
> >>> 3: eth0:  mtu 1500 qdisc fq_codel qlen
> >>> 1000
> >>> 
> >>> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> >>> inet6 fe80::a263:91ff:feea:2e14/64 scope link
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> 4: vlan1@eth0:  mtu 1500 qdisc noqueue
> >>> master br0>
> >>> 
> >>> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> >>> inet6 fe80::a263:91ff:feea:2e14/64 scope link
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> 5: vlan2@eth0:  mtu 1500 qdisc noqueue
> >>> 
> >>> link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
> >>> inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> inet6 fe80::a263:91ff:feea:2e15/64 scope link
> >>> 
> >>>valid_lft forever preferred_lft forever
> >>> 
> >>> 6: eth1:  mtu 1500 qdisc fq_codel master
> >>> br0
> >>> qlen 1000>
> >>> 
> >>> link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> >>> inet6 fe80::a263:91ff:feea:2e16/64 scope link
> >>> 
> >>>

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Noel Kuntze

Hi,

See the article about forwarding[1] that I linked previously.

Kind regards

Noel

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

On 05.09.2017 16:33, Ric S wrote:
> On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
>> Hi,
>>
>> I just noticed that your NAT rules cause problems if you try to initiate
>> connections to the RW, too. Read and apply the advice from the article
>> about NAT problems[1].
> 
> 
> 
> I added :
> 
> iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
> 
> I noticed when I ping the iPad from lan I now see that packages are matching 
> and ping changes
> 
> Chain POSTROUTING (policy ACCEPT 1320 packets, 89681 bytes)
>  pkts bytes target prot opt in out source   
> destination 
> 184 ACCEPT 0--  *  *   0.0.0.0/00.0.0.0/0 
>   policy match dir out pol ipsec 
> 
> before adding the rule:
> 
> ping R6400
> PING R6400 (192.168.0.121) 56(84) bytes of data.
> From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host Unreachable
> From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host Unreachable
> From 62.155.242.107 (62.155.242.107) icmp_seq=3 Destination Host Unreachable
> 
> 
> after adding the rule:
> 
> ping R6400
> PING R6400 (192.168.0.121) 56(84) bytes of data.
> hangs here
> 
> Thus this rule most likely is one part of the solution. 
> 
> Now I setup a second client, Win7, unlike iOS surfing the net does not work, 
> and with wireshark I see incoming TCP Retransmissions messages, looks
> like there is an issue with mtu/mss? I also managed to get one ping through 
> the tunnel to the a lan machine.
> 
> What is the best way to specify mtu sizes etc in strongswan?
> 
>>
>> Kind regards
>>
>> Noel
>>
>> [1]
>> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunn
>> eling#General-NAT-problems
>> On 05.09.2017 12:32, Ric S wrote:
>>> On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
 Hi,

> ifconfig

 Please don't use the net-tools. Use iproute2. The net-tools are woefully
 inadequate for this day and age. They are deprecated since the early
 2000s.

 Please provide the output of `ip address`, `ip route show table all`, `ip
 rule` and `sysctl -A | grep rp_filter`.

 I suspect that at least the rp_filter needs to be set to 2.
>>>
>>> I just set all interfaces to 2, still no go.
>>>
>>>
>>>
>>> root@titan:~# ip address
>>> 1: lo:  mtu 65536 qdisc noqueue qlen 1
>>>
>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
>>> 
>>>valid_lft forever preferred_lft forever
>>> 
>>> inet6 ::1/128 scope host
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 2: teql0:  mtu 1500 qdisc noop qlen 100
>>>
>>> link/void
>>>
>>> 3: eth0:  mtu 1500 qdisc fq_codel qlen 1000
>>>
>>> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::a263:91ff:feea:2e14/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 4: vlan1@eth0:  mtu 1500 qdisc noqueue
>>> master br0> 
>>> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::a263:91ff:feea:2e14/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 5: vlan2@eth0:  mtu 1500 qdisc noqueue
>>>
>>> link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
>>> 
>>>valid_lft forever preferred_lft forever
>>> 
>>> inet6 fe80::a263:91ff:feea:2e15/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 6: eth1:  mtu 1500 qdisc fq_codel master br0
>>> qlen 1000> 
>>> link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::a263:91ff:feea:2e16/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 7: eth2:  mtu 1500 qdisc fq_codel master br0
>>> qlen 1000> 
>>> link/ether a0:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::a263:91ff:feea:2e17/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 9: wl0.1:  mtu 1500 qdisc fq_codel qlen 1000
>>>
>>> link/ether a2:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.10.1/24 brd 192.168.10.255 scope global wl0.1
>>> 
>>>valid_lft forever preferred_lft forever
>>> 
>>> inet6 fe80::a063:91ff:feea:2e17/64 scope link
>>> 
>>>valid_lft forever preferred_lft forever
>>>
>>> 10: wl1.1:  mtu 1500 qdisc fq_codel qlen
>>> 1000
>>>
>>> link/ether a2:63:91:ea:2e:18 brd ff:ff:ff:ff:ff:ff
>>>

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Ric S

On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
> Hi,
> 
> I just noticed that your NAT rules cause problems if you try to initiate
> connections to the RW, too. Read and apply the advice from the article
> about NAT problems[1].



I added :

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT

I noticed when I ping the iPad from lan I now see that packages are matching 
and ping changes

Chain POSTROUTING (policy ACCEPT 1320 packets, 89681 bytes)
 pkts bytes target prot opt in out source   destination 

184 ACCEPT 0--  *  *   0.0.0.0/00.0.0.0/0   
policy match dir out pol ipsec 

before adding the rule:

ping R6400
PING R6400 (192.168.0.121) 56(84) bytes of data.
>From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host Unreachable
>From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host Unreachable
>From 62.155.242.107 (62.155.242.107) icmp_seq=3 Destination Host Unreachable


after adding the rule:

ping R6400
PING R6400 (192.168.0.121) 56(84) bytes of data.
hangs here

Thus this rule most likely is one part of the solution. 

Now I setup a second client, Win7, unlike iOS surfing the net does not work, 
and with wireshark I see incoming TCP Retransmissions messages, looks
like there is an issue with mtu/mss? I also managed to get one ping through the 
tunnel to the a lan machine.

What is the best way to specify mtu sizes etc in strongswan?

> 
> Kind regards
> 
> Noel
> 
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunn
> eling#General-NAT-problems
> On 05.09.2017 12:32, Ric S wrote:
> > On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
> >> Hi,
> >> 
> >>> ifconfig
> >> 
> >> Please don't use the net-tools. Use iproute2. The net-tools are woefully
> >> inadequate for this day and age. They are deprecated since the early
> >> 2000s.
> >> 
> >> Please provide the output of `ip address`, `ip route show table all`, `ip
> >> rule` and `sysctl -A | grep rp_filter`.
> >> 
> >> I suspect that at least the rp_filter needs to be set to 2.
> > 
> > I just set all interfaces to 2, still no go.
> > 
> > 
> > 
> > root@titan:~# ip address
> > 1: lo:  mtu 65536 qdisc noqueue qlen 1
> > 
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 ::1/128 scope host
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 2: teql0:  mtu 1500 qdisc noop qlen 100
> > 
> > link/void
> > 
> > 3: eth0:  mtu 1500 qdisc fq_codel qlen 1000
> > 
> > link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e14/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 4: vlan1@eth0:  mtu 1500 qdisc noqueue
> > master br0> 
> > link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e14/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 5: vlan2@eth0:  mtu 1500 qdisc noqueue
> > 
> > link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a263:91ff:feea:2e15/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 6: eth1:  mtu 1500 qdisc fq_codel master br0
> > qlen 1000> 
> > link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e16/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 7: eth2:  mtu 1500 qdisc fq_codel master br0
> > qlen 1000> 
> > link/ether a0:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e17/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 9: wl0.1:  mtu 1500 qdisc fq_codel qlen 1000
> > 
> > link/ether a2:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.10.1/24 brd 192.168.10.255 scope global wl0.1
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a063:91ff:feea:2e17/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 10: wl1.1:  mtu 1500 qdisc fq_codel qlen
> > 1000
> > 
> > link/ether a2:63:91:ea:2e:18 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.9.1/24 brd 192.168.9.255 scope global wl1.1
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a063:91ff:feea:2e18/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 12: br0:  mtu

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Ric S

On Dienstag, 5. September 2017 12:36:47 CEST Noel Kuntze wrote:
> Hi,
> 
> I just noticed that your NAT rules cause problems if you try to initiate
> connections to the RW, too. Read and apply the advice from the article
> about NAT problems[1].

Already tried that which didn't change anything.

> 
> Kind regards
> 
> Noel
> 
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunn
> eling#General-NAT-problems
> On 05.09.2017 12:32, Ric S wrote:
> > On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
> >> Hi,
> >> 
> >>> ifconfig
> >> 
> >> Please don't use the net-tools. Use iproute2. The net-tools are woefully
> >> inadequate for this day and age. They are deprecated since the early
> >> 2000s.
> >> 
> >> Please provide the output of `ip address`, `ip route show table all`, `ip
> >> rule` and `sysctl -A | grep rp_filter`.
> >> 
> >> I suspect that at least the rp_filter needs to be set to 2.
> > 
> > I just set all interfaces to 2, still no go.
> > 
> > 
> > 
> > root@titan:~# ip address
> > 1: lo:  mtu 65536 qdisc noqueue qlen 1
> > 
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 ::1/128 scope host
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 2: teql0:  mtu 1500 qdisc noop qlen 100
> > 
> > link/void
> > 
> > 3: eth0:  mtu 1500 qdisc fq_codel qlen 1000
> > 
> > link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e14/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 4: vlan1@eth0:  mtu 1500 qdisc noqueue
> > master br0> 
> > link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e14/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 5: vlan2@eth0:  mtu 1500 qdisc noqueue
> > 
> > link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a263:91ff:feea:2e15/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 6: eth1:  mtu 1500 qdisc fq_codel master br0
> > qlen 1000> 
> > link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e16/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 7: eth2:  mtu 1500 qdisc fq_codel master br0
> > qlen 1000> 
> > link/ether a0:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::a263:91ff:feea:2e17/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 9: wl0.1:  mtu 1500 qdisc fq_codel qlen 1000
> > 
> > link/ether a2:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.10.1/24 brd 192.168.10.255 scope global wl0.1
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a063:91ff:feea:2e17/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 10: wl1.1:  mtu 1500 qdisc fq_codel qlen
> > 1000
> > 
> > link/ether a2:63:91:ea:2e:18 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.9.1/24 brd 192.168.9.255 scope global wl1.1
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a063:91ff:feea:2e18/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 12: br0:  mtu 1500 qdisc noqueue qlen 1000
> > 
> > link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> > inet 169.254.255.1/16 brd 169.254.255.255 scope global br0:0
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet 192.168.0.1/24 brd 192.168.0.255 scope global br0
> > 
> >valid_lft forever preferred_lft forever
> > 
> > inet6 fe80::a263:91ff:feea:2e16/64 scope link
> > 
> >valid_lft forever preferred_lft forever
> > 
> > 13: ppp0:  mtu 1492 qdisc fq_codel qlen 3
> > 
> > link/ppp
> > inet 87.168.251.19 peer 62.155.242.107/32 brd 87.168.251.19 scope
> > global ppp0> 
> >valid_lft forever preferred_lft forever
> > 
> > root@titan:~# ip route show table all
> > 192.168.0.121 via 62.155.242.107 dev ppp0  table 220  proto static  src
> > 192.168.0.1 default via 62.155.242.107 dev ppp0
> > 62.155.242.107 dev ppp0  proto kernel  scope link  src 87.168.251.19
> > 127.0.0.0/8 dev lo  scope link
> > 169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
> > 192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
> > 192.168.5.0/24 dev vlan2  proto kernel

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Noel Kuntze

Hi,

I just noticed that your NAT rules cause problems if you try to initiate 
connections to the RW, too.
Read and apply the advice from the article about NAT problems[1].

Kind regards

Noel

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems


On 05.09.2017 12:32, Ric S wrote:
> On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
>> Hi,
>>
>>> ifconfig
>>
>> Please don't use the net-tools. Use iproute2. The net-tools are woefully
>> inadequate for this day and age. They are deprecated since the early 2000s.
>>
>> Please provide the output of `ip address`, `ip route show table all`, `ip
>> rule` and `sysctl -A | grep rp_filter`.
>>
>> I suspect that at least the rp_filter needs to be set to 2.
> 
> I just set all interfaces to 2, still no go.
> 
> 
> 
> root@titan:~# ip address
> 1: lo:  mtu 65536 qdisc noqueue qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host 
>valid_lft forever preferred_lft forever
> 2: teql0:  mtu 1500 qdisc noop qlen 100
> link/void 
> 3: eth0:  mtu 1500 qdisc fq_codel qlen 1000
> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::a263:91ff:feea:2e14/64 scope link 
>valid_lft forever preferred_lft forever
> 4: vlan1@eth0:  mtu 1500 qdisc noqueue master 
> br0 
> link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::a263:91ff:feea:2e14/64 scope link 
>valid_lft forever preferred_lft forever
> 5: vlan2@eth0:  mtu 1500 qdisc noqueue 
> link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
> inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
>valid_lft forever preferred_lft forever
> inet6 fe80::a263:91ff:feea:2e15/64 scope link 
>valid_lft forever preferred_lft forever
> 6: eth1:  mtu 1500 qdisc fq_codel master br0 
> qlen 1000
> link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::a263:91ff:feea:2e16/64 scope link 
>valid_lft forever preferred_lft forever
> 7: eth2:  mtu 1500 qdisc fq_codel master br0 
> qlen 1000
> link/ether a0:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::a263:91ff:feea:2e17/64 scope link 
>valid_lft forever preferred_lft forever
> 9: wl0.1:  mtu 1500 qdisc fq_codel qlen 1000
> link/ether a2:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
> inet 192.168.10.1/24 brd 192.168.10.255 scope global wl0.1
>valid_lft forever preferred_lft forever
> inet6 fe80::a063:91ff:feea:2e17/64 scope link 
>valid_lft forever preferred_lft forever
> 10: wl1.1:  mtu 1500 qdisc fq_codel qlen 1000
> link/ether a2:63:91:ea:2e:18 brd ff:ff:ff:ff:ff:ff
> inet 192.168.9.1/24 brd 192.168.9.255 scope global wl1.1
>valid_lft forever preferred_lft forever
> inet6 fe80::a063:91ff:feea:2e18/64 scope link 
>valid_lft forever preferred_lft forever
> 12: br0:  mtu 1500 qdisc noqueue qlen 1000
> link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
> inet 169.254.255.1/16 brd 169.254.255.255 scope global br0:0
>valid_lft forever preferred_lft forever
> inet 192.168.0.1/24 brd 192.168.0.255 scope global br0
>valid_lft forever preferred_lft forever
> inet6 fe80::a263:91ff:feea:2e16/64 scope link 
>valid_lft forever preferred_lft forever
> 13: ppp0:  mtu 1492 qdisc fq_codel qlen 3
> link/ppp 
> inet 87.168.251.19 peer 62.155.242.107/32 brd 87.168.251.19 scope global 
> ppp0
>valid_lft forever preferred_lft forever
> root@titan:~# ip route show table all
> 192.168.0.121 via 62.155.242.107 dev ppp0  table 220  proto static  src 
> 192.168.0.1 
> default via 62.155.242.107 dev ppp0 
> 62.155.242.107 dev ppp0  proto kernel  scope link  src 87.168.251.19 
> 127.0.0.0/8 dev lo  scope link 
> 169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
> 192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1 
> 192.168.5.0/24 dev vlan2  proto kernel  scope link  src 192.168.5.254 
> 192.168.9.0/24 dev wl1.1  proto kernel  scope link  src 192.168.9.1 
> 192.168.10.0/24 dev wl0.1  proto kernel  scope link  src 192.168.10.1 
> local 87.168.251.19 dev ppp0  table local  proto kernel  scope host  src 
> 87.168.251.19 
> broadcast 87.168.251.19 dev ppp0  table local  proto kernel  scope link  src 
> 87.168.251.19 
> broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 
> 127.0.0.1 
> local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 
> 127.0.0.1 
> local 127.0.0.1 dev lo  table local  proto kernel

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Ric S

On Dienstag, 5. September 2017 11:28:59 CEST Noel Kuntze wrote:
> Hi,
> 
> > ifconfig
> 
> Please don't use the net-tools. Use iproute2. The net-tools are woefully
> inadequate for this day and age. They are deprecated since the early 2000s.
> 
> Please provide the output of `ip address`, `ip route show table all`, `ip
> rule` and `sysctl -A | grep rp_filter`.
> 
> I suspect that at least the rp_filter needs to be set to 2.

I just set all interfaces to 2, still no go.



root@titan:~# ip address
1: lo:  mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: teql0:  mtu 1500 qdisc noop qlen 100
link/void 
3: eth0:  mtu 1500 qdisc fq_codel qlen 1000
link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a263:91ff:feea:2e14/64 scope link 
   valid_lft forever preferred_lft forever
4: vlan1@eth0:  mtu 1500 qdisc noqueue master br0 
link/ether a0:63:91:ea:2e:14 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a263:91ff:feea:2e14/64 scope link 
   valid_lft forever preferred_lft forever
5: vlan2@eth0:  mtu 1500 qdisc noqueue 
link/ether a0:63:91:ea:2e:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.254/24 brd 192.168.5.255 scope global vlan2:0
   valid_lft forever preferred_lft forever
inet6 fe80::a263:91ff:feea:2e15/64 scope link 
   valid_lft forever preferred_lft forever
6: eth1:  mtu 1500 qdisc fq_codel master br0 qlen 
1000
link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a263:91ff:feea:2e16/64 scope link 
   valid_lft forever preferred_lft forever
7: eth2:  mtu 1500 qdisc fq_codel master br0 qlen 
1000
link/ether a0:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a263:91ff:feea:2e17/64 scope link 
   valid_lft forever preferred_lft forever
9: wl0.1:  mtu 1500 qdisc fq_codel qlen 1000
link/ether a2:63:91:ea:2e:17 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global wl0.1
   valid_lft forever preferred_lft forever
inet6 fe80::a063:91ff:feea:2e17/64 scope link 
   valid_lft forever preferred_lft forever
10: wl1.1:  mtu 1500 qdisc fq_codel qlen 1000
link/ether a2:63:91:ea:2e:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.1/24 brd 192.168.9.255 scope global wl1.1
   valid_lft forever preferred_lft forever
inet6 fe80::a063:91ff:feea:2e18/64 scope link 
   valid_lft forever preferred_lft forever
12: br0:  mtu 1500 qdisc noqueue qlen 1000
link/ether a0:63:91:ea:2e:16 brd ff:ff:ff:ff:ff:ff
inet 169.254.255.1/16 brd 169.254.255.255 scope global br0:0
   valid_lft forever preferred_lft forever
inet 192.168.0.1/24 brd 192.168.0.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 fe80::a263:91ff:feea:2e16/64 scope link 
   valid_lft forever preferred_lft forever
13: ppp0:  mtu 1492 qdisc fq_codel qlen 3
link/ppp 
inet 87.168.251.19 peer 62.155.242.107/32 brd 87.168.251.19 scope global 
ppp0
   valid_lft forever preferred_lft forever
root@titan:~# ip route show table all
192.168.0.121 via 62.155.242.107 dev ppp0  table 220  proto static  src 
192.168.0.1 
default via 62.155.242.107 dev ppp0 
62.155.242.107 dev ppp0  proto kernel  scope link  src 87.168.251.19 
127.0.0.0/8 dev lo  scope link 
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1 
192.168.5.0/24 dev vlan2  proto kernel  scope link  src 192.168.5.254 
192.168.9.0/24 dev wl1.1  proto kernel  scope link  src 192.168.9.1 
192.168.10.0/24 dev wl0.1  proto kernel  scope link  src 192.168.10.1 
local 87.168.251.19 dev ppp0  table local  proto kernel  scope host  src 
87.168.251.19 
broadcast 87.168.251.19 dev ppp0  table local  proto kernel  scope link  src 
87.168.251.19 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 
127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 
127.0.0.1 
broadcast 169.254.0.0 dev br0  table local  proto kernel  scope link  src 
169.254.255.1 
local 169.254.255.1 dev br0  table local  proto kernel  scope host  src 
169.254.255.1 
broadcast 169.254.255.255 dev br0  table local  proto kernel  scope link  src 
169.254.255.1 
broadcast 192.168.0.0 dev br0  table local  proto kernel  scope link  src 
192.168.0.1 
local 192.168.0.1 dev br0  table local

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-05 Thread Noel Kuntze

Hi,

> ifconfig

Please don't use the net-tools. Use iproute2. The net-tools are woefully 
inadequate for this day and age. They
are deprecated since the early 2000s.

Please provide the output of `ip address`, `ip route show table all`, `ip rule` 
and `sysctl -A | grep rp_filter`.

I suspect that at least the rp_filter needs to be set to 2.

> 
> Just a dynamic ip, who cares.
> 

Enough people that it's RFC'd[1].

Kind regards

Noel

[1] https://tools.ietf.org/html/rfc1918#section-3

On 05.09.2017 11:06, Ric S wrote:
> Current configs now:
> 
> strongswan.conf:
> 
> charon {
> plugins {
> dhcp {
> force_server_address = yes
> server = 192.168.0.1
> identity_lease = yes
> }
> farp {
> load = yes
> }
> }}
> 
> dns1 = 8.8.8.8
> dns1 = 8.8.8.4
> 
> ipsec.conf:
> 
> config setup
>  charondebug="net 2, knl 2, cfg 2"
> 
> 
> conn ikev2
>  keyexchange=ikev2
>  
> ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes128-sha256-modp2048,aes256-aes128-sha256-sha1-modp2048-modp4096-modp1024,aes256-sha1-modp1024,aes256-sha256-modp1024,aes256-sha256-modp1536,aes2
>  
> esp=aes128-aes256-sha1-sha256-modp2048-modp4096-modp1024,aes128-sha1,aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-sha256,aes128-sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes128-sha256-modp2048,aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm
>  dpdaction=clear
>  dpddelay=60s
>  leftfirewall=yes
>  lefthostaccess=yes
>  leftid=carone.ddns.net
>  leftsubnet=192.168.0.0/24
>  leftcert=host-vpn.der
>  leftsendcert=always
>  right=%any
>  rightauth=eap-tls
>  rightsourceip=%dhcp
>  eap_identity=%any
>  auto=add
> 
> 
> On Dienstag, 5. September 2017 04:54:31 CEST you wrote:
>> Hi,
>>
>>> type=passthrough
> 
> Removed it, also did not use it previous attempts.
>>
>> You're sabotaging yourself. There is no IPsec processing happening with
>> type=passthrough
>>> threads = 8
> 
> Removed.
>>
>> You're doing it again. That can lock up the daemon later. Don't do that.
>> Luckily, the setting is outside the valid configuration block, so it's
>> invalid and ignored.
>>> interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1
> 
> I removed it. Just for the record these are my interfaces:
> 
> ifconfig
> br0   Link encap:Ethernet  HWaddr A0:XX:XX:XX:XX:16  
>   inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::a263:91ff:feea:2e16/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:5108 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:4497 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:585507 (571.7 KiB)  TX bytes:3738948 (3.5 MiB)
> 
> br0:0 Link encap:Ethernet  HWaddr A0:XX:XX:XX:XX:16  
>   inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> eth0  Link encap:Ethernet  HWaddr A0:XX:XX:XX:XX:14  
>   inet6 addr: fe80::a263:91ff:feea:2e14/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:12075 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:12590 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1941972 (1.8 MiB)  TX bytes:9910375 (9.4 MiB)
>   Interrupt:179 Base address:0x4000 
> 
> eth1  Link encap:Ethernet  HWaddr A0:XX:XX:XX:XX:16  
>   inet6 addr: fe80::a263:91ff:feea:2e16/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:7541
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>   Interrupt:163 
> 
> eth2  Link encap:Ethernet  HWaddr A0:XX:XX:XX:XX:17  
>   inet6 addr: fe80::a263:91ff:feea:2e17/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>   Interrupt:169 
> 
> loLink encap:Local Loopback  
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING MULTICAST  MTU:65536  Metric:1
>   RX packets:425 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:425 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1 
>   RX bytes:53057 (51.8 KiB)  TX bytes:53057 (51.8 KiB)
> 
> ppp0  Link encap:Point-to-Point Protocol  
>   inet addr:87.168.251.19  P-t-P:62.155.242.107

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-04 Thread noel . kuntze+strongswan-users-ml

Hi,

> type=passthrough

You're sabotaging yourself. There is no IPsec processing happening with 
type=passthrough

> threads = 8

You're doing it again. That can lock up the daemon later. Don't do that. 
Luckily, the setting is outside the valid configuration block, so it's invalid 
and ignored.

>interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1

Unnecessary.

> left=%defaultroute

Unnecessary.

> kernel-pfkey

Plugin for the legacy IPsec API. Don't use it.

>ping R6400
>PING R6400 (192.168.0.121) 56(84) bytes of data.
>From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
>Unreachable
>From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host
>Unreachable

Your next hop is sending that error. You're leaking private address into the 
WAN. That is forbidden. Don't do that.

>Routers iptable output:
>
>iptables -vnL

The output is unusable. Provide the output of `iptables-save`.
>I have tried so many thinsg, but still cannot ping from either side or
>access 
>any local machines.
>Does anyone have a clue? Can I provide additional info?

You're having no success because you're trying ramdom shit from the Internet. 
About 99,999% of the strongSwan related information on third party sites is 
wither well ng or of questinable quality. Don't get your information from any 
place but the project's website.

Kind regards

Noel



Am 5. September 2017 00:53:20 MESZ schrieb Ric S :
>Hi folks,
>
>I have been ripping my hair out with this issue.
>
>I'm running strongswan 5.5.3 on a router. The routers lan subnet is 
>192.168.0.1/24. 
>I can successfully connect to it with an Ipad with ikev2 and surf the 
>internet, but I cannot reach any internal machines.
>
>My config is the following:
>
>ipsec.conf:
>
>config setup
> charondebug="net 2, knl 2, cfg 2"
>
>conn ikev2
> keyexchange=ikev2
>ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-
>sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes1
>esp=aes128-aes256-sha1-sha256-modp2048-modp4096-modp1024,aes128-sha1,aes128-
>sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128
> dpdaction=clear
> dpddelay=60s
> left=%defaultroute
> leftfirewall=yes
> lefthostaccess=yes
> leftid=myname.ddns.net
> leftsubnet=192.168.0.0/24
> leftcert=host-vpn.der
> leftsendcert=always
> right=%any
> rightauth=eap-tls
> rightsourceip=%dhcp
> eap_identity=%any
> type=passthrough
> auto=add
>
>strongswanf.conf:
>
>charon {
>interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1
>plugins {
>dhcp {
>force_server_address = yes
>server = 192.168.0.1
>identity_lease = yes
>}
>farp {
>load = yes
>}
>}}
>
>threads = 8
>dns1 = 8.8.8.8
>dns1 = 8.8.8.4
>
>
>
>Status:
>
>Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.80, armv7l):
>  uptime: 14 minutes, since Sep 05 00:09:53 2017
>  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
>scheduled: 8
>loaded plugins: charon test-vectors aes des blowfish rc2 sha2 sha1 md5 
>random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8
>pkcs12 pgp 
>dnskey sshkey pem openssl fips-prf gmp curve25519 agent xcbc cmac hmac
>sqlite 
>attr kernel-pfkey kernel-netlink resolve socket-default farp stroke
>vici 
>updown eap-identity eap-aka eap-md5 eap-mschapv2 eap-radius eap-tls
>xauth-
>generic xauth-eap dhcp whitelist led duplicheck
>Listening IP addresses:
>  169.254.255.1
>  192.168.0.1
>  87.168.243.83
>Connections:
>   ikev2:  %any...%any  IKEv2, dpddelay=60s
>  ikev2:   local:  [myname.ddns.net] uses public key authentication
>   ikev2:cert:  "C=DE, O=MYORG, CN=myname.ddns.net"
>  ikev2:   remote: uses EAP_TLS authentication with EAP identity '%any'
>  ikev2:   child:  192.168.0.0/24 === dynamic PASS, dpdaction=clear
>Security Associations (1 up, 0 connecting):
>ikev2[6]: ESTABLISHED 11 seconds ago, 87.168.243.83[myname.ddns.net]...
>109.43.1.19[R6400]
>  ikev2[6]: IKEv2 SPIs: 243db36d71718704_i 688c466c497d2b9a_r*, public 
>key reauthentication in 2 hours
>   ikev2[6]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/
>MODP_1024
>ikev2{4}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c0983fe7_i 
>04eb0f50_o
>   ikev2{4}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, 
>rekeying in 48 minutes
>   ikev2{4}:   192.168.0.0/24 === 192.168.0.121/32
>
>swanctl --list-sas
>ikev2: #6, ESTABLISHED, IKEv2, 243db36d71718704_i 688c466c497d2b9a_r*
>  local  'myname.ddns.net' @ 87.168.243.83[4500]
>  remote 'R6400' @ 109.43.1.19[39898] [192.168.0.121]
>  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>  established 92s ago, reauth in 9765s
>  ikev2: #4, reqid 3, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
>HMAC_SHA2_256_128
>installed 89s ago, rekeying in 2800s, expires in 3511s
>in  c0983fe7,  0 bytes, 0 packets
>out 04eb0f50,  0 bytes, 0 packets
>local  192.168.0.0/24
>remote 192.168.0.121/32
>
>ip route

Re: [strongSwan] Cannot ping machines on remote local network

2017-09-04 Thread Bas van Dijk

Hi Ric,

Is IP forwarding enabled on the router?

sysctl net.ipv4.ip_forward=1

Bas

On 5 Sep 2017 12:53 AM, "Ric S"  wrote:

> Hi folks,
>
> I have been ripping my hair out with this issue.
>
> I'm running strongswan 5.5.3 on a router. The routers lan subnet is
> 192.168.0.1/24.
> I can successfully connect to it with an Ipad with ikev2 and surf the
> internet, but I cannot reach any internal machines.
>
> My config is the following:
>
> ipsec.conf:
>
> config setup
>  charondebug="net 2, knl 2, cfg 2"
>
> conn ikev2
>  keyexchange=ikev2
>  ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-
> modp2048,aes128-
> sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes1
>  esp=aes128-aes256-sha1-sha256-modp2048-modp4096-
> modp1024,aes128-sha1,aes128-
> sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128
>  dpdaction=clear
>  dpddelay=60s
>  left=%defaultroute
>  leftfirewall=yes
>  lefthostaccess=yes
>  leftid=myname.ddns.net
>  leftsubnet=192.168.0.0/24
>  leftcert=host-vpn.der
>  leftsendcert=always
>  right=%any
>  rightauth=eap-tls
>  rightsourceip=%dhcp
>  eap_identity=%any
>  type=passthrough
>  auto=add
>
> strongswanf.conf:
>
> charon {
> interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1
> plugins {
> dhcp {
> force_server_address = yes
> server = 192.168.0.1
> identity_lease = yes
> }
> farp {
> load = yes
> }
> }}
>
> threads = 8
> dns1 = 8.8.8.8
> dns1 = 8.8.8.4
>
>
>
> Status:
>
> Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.80, armv7l):
>   uptime: 14 minutes, since Sep 05 00:09:53 2017
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 8
>   loaded plugins: charon test-vectors aes des blowfish rc2 sha2 sha1 md5
> random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12
> pgp
> dnskey sshkey pem openssl fips-prf gmp curve25519 agent xcbc cmac hmac
> sqlite
> attr kernel-pfkey kernel-netlink resolve socket-default farp stroke vici
> updown eap-identity eap-aka eap-md5 eap-mschapv2 eap-radius eap-tls xauth-
> generic xauth-eap dhcp whitelist led duplicheck
> Listening IP addresses:
>   169.254.255.1
>   192.168.0.1
>   87.168.243.83
> Connections:
>ikev2:  %any...%any  IKEv2, dpddelay=60s
>ikev2:   local:  [myname.ddns.net] uses public key authentication
>ikev2:cert:  "C=DE, O=MYORG, CN=myname.ddns.net"
>ikev2:   remote: uses EAP_TLS authentication with EAP identity
> '%any'
>ikev2:   child:  192.168.0.0/24 === dynamic PASS, dpdaction=clear
> Security Associations (1 up, 0 connecting):
>ikev2[6]: ESTABLISHED 11 seconds ago, 87.168.243.83[myname.ddns.net
> ]...
> 109.43.1.19[R6400]
>ikev2[6]: IKEv2 SPIs: 243db36d71718704_i 688c466c497d2b9a_r*, public
> key reauthentication in 2 hours
>ikev2[6]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/
> MODP_1024
>ikev2{4}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c0983fe7_i
> 04eb0f50_o
>ikev2{4}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o,
> rekeying in 48 minutes
>ikev2{4}:   192.168.0.0/24 === 192.168.0.121/32
>
> swanctl --list-sas
> ikev2: #6, ESTABLISHED, IKEv2, 243db36d71718704_i 688c466c497d2b9a_r*
>   local  'myname.ddns.net' @ 87.168.243.83[4500]
>   remote 'R6400' @ 109.43.1.19[39898] [192.168.0.121]
>   AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>   established 92s ago, reauth in 9765s
>   ikev2: #4, reqid 3, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
> HMAC_SHA2_256_128
> installed 89s ago, rekeying in 2800s, expires in 3511s
> in  c0983fe7,  0 bytes, 0 packets
> out 04eb0f50,  0 bytes, 0 packets
> local  192.168.0.0/24
> remote 192.168.0.121/32
>
> ip route list table 220
> 192.168.0.121 via 62.155.242.107 dev ppp0  proto static  src 192.168.0.1
>
> FARP seems to work, this is a ping from one of the local machines:
>
> ping R6400
> PING R6400 (192.168.0.121) 56(84) bytes of data.
> From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host
> Unreachable
> From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host
> Unreachable
>
>
> Routers iptable output:
>
> iptables -vnL
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT 0--  ppp0   *   192.168.0.121
> 192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50
>   161 29398 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> udp dpt:4500
> 8  4544 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> udp dpt:500
> 0 0 log
> ...
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT 0--  ppp0   *   192.168.0.121
> 192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50
> 0 0 ACCEPT 0--  *

[strongSwan] Cannot ping machines on remote local network

2017-09-04 Thread Ric S

Hi folks,

I have been ripping my hair out with this issue.

I'm running strongswan 5.5.3 on a router. The routers lan subnet is 
192.168.0.1/24. 
I can successfully connect to it with an Ipad with ikev2 and surf the 
internet, but I cannot reach any internal machines.

My config is the following:

ipsec.conf:

config setup
 charondebug="net 2, knl 2, cfg 2"

conn ikev2
 keyexchange=ikev2
 ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-
sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes1
 esp=aes128-aes256-sha1-sha256-modp2048-modp4096-modp1024,aes128-sha1,aes128-
sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128
 dpdaction=clear
 dpddelay=60s
 left=%defaultroute
 leftfirewall=yes
 lefthostaccess=yes
 leftid=myname.ddns.net
 leftsubnet=192.168.0.0/24
 leftcert=host-vpn.der
 leftsendcert=always
 right=%any
 rightauth=eap-tls
 rightsourceip=%dhcp
 eap_identity=%any
 type=passthrough
 auto=add

strongswanf.conf:

charon {
interfaces_ignore = vlan2, eth0, eth1, eth2, wl0.1, wl1.1
plugins {
dhcp {
force_server_address = yes
server = 192.168.0.1
identity_lease = yes
}
farp {
load = yes
}
}}

threads = 8
dns1 = 8.8.8.8
dns1 = 8.8.8.4



Status:

Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.80, armv7l):
  uptime: 14 minutes, since Sep 05 00:09:53 2017
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 8
  loaded plugins: charon test-vectors aes des blowfish rc2 sha2 sha1 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp 
dnskey sshkey pem openssl fips-prf gmp curve25519 agent xcbc cmac hmac sqlite 
attr kernel-pfkey kernel-netlink resolve socket-default farp stroke vici 
updown eap-identity eap-aka eap-md5 eap-mschapv2 eap-radius eap-tls xauth-
generic xauth-eap dhcp whitelist led duplicheck
Listening IP addresses:
  169.254.255.1
  192.168.0.1
  87.168.243.83
Connections:
   ikev2:  %any...%any  IKEv2, dpddelay=60s
   ikev2:   local:  [myname.ddns.net] uses public key authentication
   ikev2:cert:  "C=DE, O=MYORG, CN=myname.ddns.net"
   ikev2:   remote: uses EAP_TLS authentication with EAP identity '%any'
   ikev2:   child:  192.168.0.0/24 === dynamic PASS, dpdaction=clear
Security Associations (1 up, 0 connecting):
   ikev2[6]: ESTABLISHED 11 seconds ago, 87.168.243.83[myname.ddns.net]...
109.43.1.19[R6400]
   ikev2[6]: IKEv2 SPIs: 243db36d71718704_i 688c466c497d2b9a_r*, public 
key reauthentication in 2 hours
   ikev2[6]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/
MODP_1024
   ikev2{4}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c0983fe7_i 
04eb0f50_o
   ikev2{4}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, 
rekeying in 48 minutes
   ikev2{4}:   192.168.0.0/24 === 192.168.0.121/32

swanctl --list-sas
ikev2: #6, ESTABLISHED, IKEv2, 243db36d71718704_i 688c466c497d2b9a_r*
  local  'myname.ddns.net' @ 87.168.243.83[4500]
  remote 'R6400' @ 109.43.1.19[39898] [192.168.0.121]
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 92s ago, reauth in 9765s
  ikev2: #4, reqid 3, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/
HMAC_SHA2_256_128
installed 89s ago, rekeying in 2800s, expires in 3511s
in  c0983fe7,  0 bytes, 0 packets
out 04eb0f50,  0 bytes, 0 packets
local  192.168.0.0/24
remote 192.168.0.121/32

ip route list table 220
192.168.0.121 via 62.155.242.107 dev ppp0  proto static  src 192.168.0.1

FARP seems to work, this is a ping from one of the local machines:

ping R6400
PING R6400 (192.168.0.121) 56(84) bytes of data.
>From 62.155.242.107 (62.155.242.107) icmp_seq=1 Destination Host Unreachable
>From 62.155.242.107 (62.155.242.107) icmp_seq=2 Destination Host Unreachable


Routers iptable output:

iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination 
0 0 ACCEPT 0--  ppp0   *   192.168.0.121
192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50 
  161 29398 ACCEPT udp  --  *  *   0.0.0.0/00.0.0.0/0   

udp dpt:4500 
8  4544 ACCEPT udp  --  *  *   0.0.0.0/00.0.0.0/0   

udp dpt:500 
0 0 log
...

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination 
0 0 ACCEPT 0--  ppp0   *   192.168.0.121
192.168.0.0/24  policy match dir in pol ipsec reqid 4 proto 50 
0 0 ACCEPT 0--  *  ppp0192.168.0.0/24   
192.168.0.121   policy match dir out pol ipsec reqid 4 proto 50 
...

Chain OUTPUT (policy ACCEPT 480K packets, 377M bytes)
 pkts bytes target prot opt in out source   
destination 
0 0 ACCEPT 0--  *  ppp0

Re: [strongSwan] Cannot ping machines on remote local network - solved

Re: [strongSwan] Cannot ping machines on remote local network - solved

Re: [strongSwan] Cannot ping machines on remote local network - solved

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

Re: [strongSwan] Cannot ping machines on remote local network

[strongSwan] Cannot ping machines on remote local network

14 matches

Site Navigation

Mail list logo

Footer information