Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
StrongSwan+FreeBSD 10.2+FreeBSD 11+enc0 does not work
493 views
Skip to first unread message
Max Id
Jan 24, 2016, 7:15:30 PM1/24/16
to
Good day,
I've set up a FreeBSD-based VPN server using StrongSwan daemon( IKEv2 ).
I can connect to this VPN server from Windows 8.1 box or BlackBerry
Passport ( IKE2 ), everything works perfectly, I have access to both
Internet behind VPN server and VPN server resources, such as DLNA.
Now I am trying to set up FreeBSD-based client using StrongSwan daemon as
well, but the tunnel does not seem to be working.
Setup:
Client( releng/10.2, bfe0 192.168.1.132, enc0 )
Server( current/11, em0 192.168.11.1, em1 96.200.XX.XX, enc0 )
The firewalls on both boxes are 100% disabled ( pfctl -d ), so they do not
interfere.
I set up an IKEv2 authentication based on certificates, similarly as for
Windows and Blackberry clients.
The server is configured to assign vpn clients virtual addresses from the
pool 10.0.11.0/28.
I then bring up VPN client on client box. A new interface, tun0, is created
and assigned the address 10.0.11.1, which is perfectly correct.
StrongSwan daemons on both boxes say the VPN SA connection is successfully
established.
The command netstat -rn on the server shows a new entry for 10.0.11.1,
which is also correct ( the same was for BlackBerry and Windows ).
I perform few tests to check if the tunnel is actually working. All the
tests are performed on enc0 interface, which should inherit all IPSec
traffic.The sysctl parameters for enc0 interface are set according to
manual, to peel off the outer UDP packet header.
Test 1. I run the following command on client:
ping 192.168.11.1, which should ping the internal server's interface.
tcpdump -i enc0 on client shows non-decapsulated icmp request followed by
decapsulated icmp request.
tcpdump -i enc0 on server shows non-decapsulated icmp request only.
replies are not shown.
Test 2. I run the following command on server:
ping 10.0.11.1, which should ping the client's virtual VPN address.
tcpdump -i enc0 on client shows non-decapsulated icmp request,
non-decapsulated icmp reply and also decapsulated icmp reply.
tcpdump -i enc0 on server shows non-decapsulated icmp request,
non-decapsulated icmp reply and also decapsulated icmp request.
In any case, on any box, ping utility reports 100% packet loss.
I am wondering if it is bug in kernel, or strongswan, or the wrong setup.
Seems like there are some problems with decapsulation, because in most
cases I do not see decapsulated packet.
Any response will be really appreciated.
Thanks, Max.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
I've set up a FreeBSD-based VPN server using StrongSwan daemon( IKEv2 ).
I can connect to this VPN server from Windows 8.1 box or BlackBerry
Passport ( IKE2 ), everything works perfectly, I have access to both
Internet behind VPN server and VPN server resources, such as DLNA.
Now I am trying to set up FreeBSD-based client using StrongSwan daemon as
well, but the tunnel does not seem to be working.
Setup:
Client( releng/10.2, bfe0 192.168.1.132, enc0 )
Server( current/11, em0 192.168.11.1, em1 96.200.XX.XX, enc0 )
The firewalls on both boxes are 100% disabled ( pfctl -d ), so they do not
interfere.
I set up an IKEv2 authentication based on certificates, similarly as for
Windows and Blackberry clients.
The server is configured to assign vpn clients virtual addresses from the
pool 10.0.11.0/28.
I then bring up VPN client on client box. A new interface, tun0, is created
and assigned the address 10.0.11.1, which is perfectly correct.
StrongSwan daemons on both boxes say the VPN SA connection is successfully
established.
The command netstat -rn on the server shows a new entry for 10.0.11.1,
which is also correct ( the same was for BlackBerry and Windows ).
I perform few tests to check if the tunnel is actually working. All the
tests are performed on enc0 interface, which should inherit all IPSec
traffic.The sysctl parameters for enc0 interface are set according to
manual, to peel off the outer UDP packet header.
Test 1. I run the following command on client:
ping 192.168.11.1, which should ping the internal server's interface.
tcpdump -i enc0 on client shows non-decapsulated icmp request followed by
decapsulated icmp request.
tcpdump -i enc0 on server shows non-decapsulated icmp request only.
replies are not shown.
Test 2. I run the following command on server:
ping 10.0.11.1, which should ping the client's virtual VPN address.
tcpdump -i enc0 on client shows non-decapsulated icmp request,
non-decapsulated icmp reply and also decapsulated icmp reply.
tcpdump -i enc0 on server shows non-decapsulated icmp request,
non-decapsulated icmp reply and also decapsulated icmp request.
In any case, on any box, ping utility reports 100% packet loss.
I am wondering if it is bug in kernel, or strongswan, or the wrong setup.
Seems like there are some problems with decapsulation, because in most
cases I do not see decapsulated packet.
Any response will be really appreciated.
Thanks, Max.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
CeDeROM
Jan 25, 2016, 2:59:56 AM1/25/16
to
maxi...@gmail.com
Jan 25, 2016, 3:07:59 AM1/25/16
to
Max Id
Jan 25, 2016, 3:22:32 AM1/25/16
to
Racoon does not support IKEv2, racoon2 is needed for that.
Both solutions are very old, barely maintained, and more Linux-specific (
racoon/IPSec ).
Also, StrongSwan works perfectly, the problem is only in FreeBSD to
FreeBSD connection :)
Both solutions are very old, barely maintained, and more Linux-specific (
racoon/IPSec ).
Also, StrongSwan works perfectly, the problem is only in FreeBSD to
FreeBSD connection :)
On Monday, January 25, 2016, CeDeROM <ced...@tlen.pl> wrote:
> Why dont you try Racoon instead of StrongSwan? :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
CeDeROM
Jan 25, 2016, 4:06:45 AM1/25/16
to
Racoon from ipsec tools can do that I guess. I recently set connection
between Linux and Juniper using FreeBSD configuration :-)
Did you setkey? What setkey -DP show?
Maybe a firewall problem?
Home routers can only pass one VPN session at time.
Try to run daemon in foreground verbose debug to see where is the problem
:-)
Tomek
between Linux and Juniper using FreeBSD configuration :-)
Did you setkey? What setkey -DP show?
Maybe a firewall problem?
Home routers can only pass one VPN session at time.
Try to run daemon in foreground verbose debug to see where is the problem
:-)
Tomek
Max Id
Jan 25, 2016, 5:21:15 AM1/25/16
to
StrongSwan is an automatic keying daemon, and thus does not require any
manual IPSeac config tool.
The logs of strongswan do not show any errors, both daemons report the
connection is established. Even the routing table entry is added. As I
said, the firewalls are disabled, so they do not interfere with testing.
manual IPSeac config tool.
The logs of strongswan do not show any errors, both daemons report the
connection is established. Even the routing table entry is added. As I
said, the firewalls are disabled, so they do not interfere with testing.
CeDeROM
Jan 25, 2016, 6:44:30 AM1/25/16
to
No clue sorry, never used StrongSwan :-( Maybe try with previous
FreeBSD release to check if anything changed in driver/kernel..? Good
luck! :-)
FreeBSD release to check if anything changed in driver/kernel..? Good
luck! :-)
Max Id
Jan 25, 2016, 7:01:04 PM1/25/16
to
Just in case if you're still interested...
The parameter "compress=yes" in StrongSwan's config was to blame...
Discovered this by enabling ipsec debug sysctl variable.
Thanks, Maksym.
The parameter "compress=yes" in StrongSwan's config was to blame...
Discovered this by enabling ipsec debug sysctl variable.
Thanks, Maksym.
CeDeROM
Jan 26, 2016, 2:55:07 AM1/26/16
to
On Tue, Jan 26, 2016 at 1:00 AM, Max Id <maxi...@gmail.com> wrote:
> The parameter "compress=yes" in StrongSwan's config was to blame...
> Discovered this by enabling ipsec debug sysctl variable.
Heh :D Thanks Max for sharing the solution! =)
> The parameter "compress=yes" in StrongSwan's config was to blame...
> Discovered this by enabling ipsec debug sysctl variable.
0 new messages