No vpn shrew to out

Hello, I can’t connect to Shrew VPN when I’m connected via ipfire. Everything should be open to the outside world. If I set up the WLAN to the Fritzbox, it works immediately, also using a cell phone hotspot.
I can’t find any error in the rules and in the log I can also find a small hint. Can someone help me?
openvpn and wireguard works without problems

has this worked in the past and then suddenly stopped working?

Keep in mid the client software for Shrew is almost 10 years old. Maybe something has changed?!?

2 Likes

No, nothing has changed. This condition has been around for a long time, but I wanted to clarify why this is because, as I said, if I’m connected directly to the Fritz or a hotspot via WiFi, everything works from the same device. I just don’t understand why the IPFIRE obviously doesn’t allow something from the inside out

Perhaps a diagram of traffic to and from.
Vpn, wan of ipfire to green client running vpn?
Vpn, wan of ipfire to green network ?

draw.io has a nice site for creating a drawing.

2 Likes

ok if it helps? But thought this is understandable as I wrote it?

In the firewall, nothing is restricted to the outside. Every client can go anywhere. There are only restrictions due to a pihole, but I switched it off as a test.

Internet - Fritzbox - ipfire - notebook with VPN client “shrew”
Internet to the outside is not restricted but a VPN connection to the opposing Fritzbox is not established

Internet - Fritzbox - Notebook with VPN Client “shrew”
Internet to the outside is not restricted, a VPN connection to the opposing Fritzbox is established

Internet - hotspot on mobile phone - notebook with VPN client “shrew”
Internet to the outside is not restricted, a VPN connection to the opposing Fritzbox is established

If you turn off firewall rules 1,2,3,and 4. Try that.
Should not be needed in default configuration.

That’s not true and it doesn’t bring any change. I already knew before

Rule no3 puts me behind the firewall on an external wireguard server.
In addition, by disabling rule No3, I no longer get a connection to the firewall’s web interface.

Despite this, I have deactivated all the rules and the connection is still not established.
This

You should not need any firewall rule to access the WUI interface from a machine on the green lan so if it is true that you have to have that rule then there must be some issue somewhere. I have never had to create a rule to allow WUI access from the green network on my production system or any of my testbed vm machines.

I don’t really understand why you want to have a VPN connection between a machine on your green network and the Fritzbox.
Likely any problem would be related to the particular IP range the lan portion of your Fritzbox has and what it sees as its FQDN compared to what has been entered into the shrew vpn client.

you misunderstand me or it was mistranslated.
on the one hand I can access the WUI from the green network, but not if I am connected via openvpn. Hence this rule regarding Openvpn.

I also do not need a VPN connection between ipfire and Fritzbox but from a PV behind the IPFIRE to a Fritzbox at another location.

sorry if I expressed myself unclearly

Ah, sorry. So there is a second Fritzbox which is somewhere else on the Internet.

To be sure I am understanding is the connection between your laptop with shrew and the remote Fritzbox a Roadwarrior connection?

yes only a single connection to a Fritzbox at a sports club to get into its network

Then I would look at the vpn logs on the laptop client to see how far, if at all it gets through the tunnel setup communication flow.

As the server end is a Fritzbox belonging to another organisation, I suspect you will not be able to get access to their logs to see if anything gets through to their end and then is stopped for some reason or if nothing gets to them at all.
Only thing I can think of is to use something like tshark to track the communication and see what gets to the output of IPFire.

but I can fully access both because I can successfully establish the connection if I connect to the LAN of my own Fritzbox and thus bypass my ipfire.
That’s what I don’t understand, since the ipfire is obviously doing something here.

So the log of the Fritzbox on the Internet says nothing. Apparently nothing comes of it.
I have a log of the ShrewClient but I don’t understand the messages. Maybe you can translate something?

22/08/01 15:00:17 ## : IKE Daemon, ver 2.2.2
22/08/01 15:00:17 ## : Copyright 2013 Shrew Soft Inc.
22/08/01 15:00:17 ## : This product linked OpenSSL 1.0.1c 10 May 2012
22/08/01 15:00:17 ii : opened ‘C:\Program Files\ShrewSoft\VPN Client\debug\iked.log’
22/08/01 15:00:17 ii : opened ‘C:\Program Files\ShrewSoft\VPN Client/debug/dump-ike-decrypt.cap’
22/08/01 15:00:17 ii : opened ‘C:\Program Files\ShrewSoft\VPN Client/debug/dump-ike-encrypt.cap’
22/08/01 15:00:17 ii : rebuilding vnet device list …
22/08/01 15:00:17 ii : device ROOT\VNET\0000 disabled
22/08/01 15:00:17 ii : network process thread begin …
22/08/01 15:00:17 ii : ipc server process thread begin …
22/08/01 15:00:17 ii : pfkey process thread begin …
22/08/01 15:00:25 !! : unable to connect to pfkey interface
22/08/01 15:01:10 ii : ipc client process thread begin …
22/08/01 15:01:10 <A : peer config add message
22/08/01 15:01:10 <A : proposal config message
22/08/01 15:01:10 <A : proposal config message
22/08/01 15:01:10 <A : client config message
22/08/01 15:01:10 <A : xauth username message
22/08/01 15:01:10 <A : xauth password message
22/08/01 15:01:10 <A : local id ‘admin’ message
22/08/01 15:01:10 <A : preshared key message
22/08/01 15:01:10 <A : remote resource message
22/08/01 15:01:10 <A : peer tunnel enable message
22/08/01 15:01:10 DB : peer added ( obj count = 1 )
22/08/01 15:01:10 ii : local address 192.168.150.10 selected for peer
22/08/01 15:01:10 DB : tunnel added ( obj count = 1 )
22/08/01 15:01:10 DB : new phase1 ( ISAKMP initiator )
22/08/01 15:01:10 DB : exchange type is aggressive
22/08/01 15:01:10 DB : 192.168.150.10:500 <-> 84.56.255.137:500
22/08/01 15:01:10 DB : af9aad627e0f6eec:0000000000000000
22/08/01 15:01:10 DB : phase1 added ( obj count = 1 )
22/08/01 15:01:10 >> : security association payload
22/08/01 15:01:10 >> : - proposal #1 payload
22/08/01 15:01:10 >> : – transform #1 payload
22/08/01 15:01:10 >> : – transform #2 payload
22/08/01 15:01:10 >> : – transform #3 payload
22/08/01 15:01:10 >> : – transform #4 payload
22/08/01 15:01:10 >> : – transform #5 payload
22/08/01 15:01:10 >> : – transform #6 payload
22/08/01 15:01:10 >> : – transform #7 payload
22/08/01 15:01:10 >> : – transform #8 payload
22/08/01 15:01:10 >> : – transform #9 payload
22/08/01 15:01:10 >> : – transform #10 payload
22/08/01 15:01:10 >> : – transform #11 payload
22/08/01 15:01:10 >> : – transform #12 payload
22/08/01 15:01:10 >> : – transform #13 payload
22/08/01 15:01:10 >> : – transform #14 payload
22/08/01 15:01:10 >> : – transform #15 payload
22/08/01 15:01:10 >> : – transform #16 payload
22/08/01 15:01:10 >> : – transform #17 payload
22/08/01 15:01:10 >> : – transform #18 payload
22/08/01 15:01:10 >> : key exchange payload
22/08/01 15:01:10 >> : nonce payload
22/08/01 15:01:10 >> : identification payload
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports XAUTH
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports nat-t ( draft v00 )
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports nat-t ( draft v01 )
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports nat-t ( draft v02 )
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports nat-t ( draft v03 )
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports nat-t ( rfc )
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports FRAGMENTATION
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local supports DPDv1
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local is SHREW SOFT compatible
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local is NETSCREEN compatible
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local is SIDEWINDER compatible
22/08/01 15:01:10 >> : vendor id payload
22/08/01 15:01:10 ii : local is CISCO UNITY compatible
22/08/01 15:01:10 >= : cookies af9aad627e0f6eec:0000000000000000
22/08/01 15:01:10 >= : message 00000000
22/08/01 15:01:10 → : send IKE packet 192.168.150.10:500 → 84.56.255.137:500 ( 1201 bytes )
22/08/01 15:01:10 DB : phase1 resend event scheduled ( ref count = 2 )
22/08/01 15:01:16 → : resend 1 phase1 packet(s) [0/2] 192.168.150.10:500 → 84.56.255.137:500
22/08/01 15:01:21 → : resend 1 phase1 packet(s) [1/2] 192.168.150.10:500 → 84.56.255.137:500
22/08/01 15:01:26 → : resend 1 phase1 packet(s) [2/2] 192.168.150.10:500 → 84.56.255.137:500
22/08/01 15:01:31 ii : resend limit exceeded for phase1 exchange
22/08/01 15:01:31 ii : phase1 removal before expire time
22/08/01 15:01:31 DB : phase1 deleted ( obj count = 0 )
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : policy not found
22/08/01 15:01:31 DB : removing tunnel config references
22/08/01 15:01:31 DB : removing tunnel phase2 references
22/08/01 15:01:31 DB : removing tunnel phase1 references
22/08/01 15:01:31 DB : tunnel deleted ( obj count = 0 )
22/08/01 15:01:31 DB : removing all peer tunnel references
22/08/01 15:01:31 DB : peer deleted ( obj count = 0 )
22/08/01 15:01:31 ii : ipc client process thread exit …
22/08/01 15:02:57 !! : unable to connect to pfkey interface
22/08/01 15:02:58 !! : unable to connect to pfkey interface
22/08/01 15:02:59 !! : unable to connect to pfkey interface
22/08/01 15:03:00 !! : unable to connect to pfkey interface
22/08/01 15:03:01 !! : unable to connect to pfkey interface
22/08/01 15:03:02 !! : unable to connect to pfkey interface
22/08/01 15:03:03 !! : unable to connect to pfkey interface
22/08/01 15:03:04 !! : unable to connect to pfkey interface

I am not familiar with windows stuff but I notice that the first line in the log is

I went and looked at the shrew site and confirmed that shrew is an IPSec client. You mentioned earlier that the connection worked when using OpenVPN so that would suggest that the remote Fritzbox has an OpenVPN server for connection.
Does it also have a separate IPSec VPN server? If not then the shrew client won’t work with an OpenVPN server.

A separate observation, the shrew log states

OpenSSL 1.0.1c is very old. Currently IPFire is running with 1.1.1.p
Separate from the OpenVPN/IPSec question having software trying to work with OpenSSL versions so far apart runs the risk of mismatches in what is allowed between the two versions plus the older version will have lots of vulnerabilities that have been fixed in the newer versions.

ok, then I’ll part with the client shortly. AVM still supports it, but will soon also offer wireguard.
Thanks for the support

Fritzbox it self does not support OpenVPN nor IKEV2: https://en.avm.de/service/knowledge-base/dok/FRITZ-Box-7490/3342_Supported-VPN-providers/

Then then the OpenVPN server must be on a machine behind the sport centres Fritzbox.

Hi,

Openvpn and watchguard work well with nat and firewalling.
IKE on the other hand is notoriously difficult to get right with firewalls yet alone different types of devices.
My advice is stick to OpenVPN or watchguard and make your life simple.

BR
Joe.