Hi All -
Where I work uses the Shrew Soft VPN client to access remote resources. I have found pre-built rpms for EL5, various versions of Fedora, and appropriate packages for non-rpm based distros but no rpm for EL6. I have downloaded the source from Shrew Soft and built "my own" which built and installed with no errors but then didn't work. I'm finally taking the lack of pre-built rpms for EL6 as a clue that there is some sort of inherent problem getting this VPN client working under EL6. Is there a problem with Shrew Soft and EL6? If so, are there any work-arounds?
Background: I also have the Shrew Soft VPN client (rpm installed) for FC16 running on my FC16 box on the same network as my EL6 box so I have a known working configuration and know that there are no firewall issues. This same configuration and user connects under EL6 (confirmed on the VPN server) but is unusable (e.g., I can't ping known systems).
Thanks, Dave
Hi, Dave,
dave@davenjudy.org wrote:
Where I work uses the Shrew Soft VPN client to access remote resources. I have found pre-built rpms for EL5, various versions of Fedora, and appropriate packages for non-rpm based distros but no rpm for EL6. I have downloaded the source from Shrew Soft and built "my own" which built and installed with no errors but then didn't work. I'm finally taking the
<snip>
same configuration and user connects under EL6 (confirmed on the VPN server) but is unusable (e.g., I can't ping known systems).
I think I'd try tcpdump, or some other tool, and see what's happening.
mark
<m.roth@...> writes:
Hi, Dave,
dave@... wrote:
Where I work uses the Shrew Soft VPN client to access remote resources. I have found pre-built rpms for EL5, various versions of Fedora, and appropriate packages for non-rpm based distros but no rpm for EL6. I have downloaded the source from Shrew Soft and built "my own" which built and installed with no errors but then didn't work. I'm finally taking the
<snip> > same configuration and user connects under EL6 (confirmed on the VPN > server) but is unusable (e.g., I can't ping known systems).
I think I'd try tcpdump, or some other tool, and see what's happening.
mark
I ran tcpdump on my gateway's interface to the the 'net while running a ping on the client. I could see what I'm pretty sure were the ping returns (hard to tell since it's VPN traffic). I'll move the tcpdump to watching what goes from the gateway to the VPN client although the VPN traffic will then be mixed in with any other non-VPN traffic between the client and my gateway. I can cut back on this traffic but I can't stop it or filter it the way I cann at the gateway's exterior NIC.
I'm pretty sure the problem has to do with the VPN stack on the VPN client. The FC16 box uses the same client and the same configuration to successfully connect to the VPN and access remote systems but there are several dependent libraries that are newer on the FC16 platform (I tried installing the FC16 rpm on my EL6 box to 1) see if it would install and 2) see what dependencies changed). There could be something wrong with how the outbound packets get built but then I probably wouldn't have seen the pings coming back.
Cheers, Dave
On Fri, Feb 24, 2012 at 4:30 PM, David G. Miller dave@davenjudy.org wrote:
I think I'd try tcpdump, or some other tool, and see what's happening.
I ran tcpdump on my gateway's interface to the the 'net while running a ping on the client. I could see what I'm pretty sure were the ping returns (hard to tell since it's VPN traffic). I'll move the tcpdump to watching what goes from the gateway to the VPN client although the VPN traffic will then be mixed in with any other non-VPN traffic between the client and my gateway. I can cut back on this traffic but I can't stop it or filter it the way I cann at the gateway's exterior NIC.
Does the VPN create its own tun interface? If so tcpdump should be able to see the decrypted packets entering and leaving there.
Les Mikesell <lesmikesell@...> writes:
On Fri, Feb 24, 2012 at 4:30 PM, David G. Miller <dave@...> wrote:
I ran tcpdump on my gateway's interface to the the 'net while running a ping on
Does the VPN create its own tun interface? If so tcpdump should be able to see the decrypted packets entering and leaving there.
It gets a LAN address. Whether it can work when bridged is a different question. On the FC16 box with the working VPN client, no packets actually hit the tap0 device that has the LAN address.
Cheers, Dave
David G. Miller <dave@...> writes:
Les Mikesell <lesmikesell@...> writes:
On Fri, Feb 24, 2012 at 4:30 PM, David G. Miller <dave@...> wrote:
<SNIP> Recap: I could build and run the Shrew Soft VPN client but I couldn't get packets back to the application process. They made it to the NIC on the box running the application but something weeded them out rather than delivering them.
After much Googling and advice from folks like Les as well as following the advice in other message postings (that didn't work), I finally found this article in the Shrew Soft VPN-help archive:
http://lists.shrew.net/pipermail/vpn-help/2008-November/000950.html
Using this advice, I now have the VPN running. The effect of setting the various values for rp_filter aren't immediate and the one specified (net.ipv4.conf.all.rp_filter) to set to zero was already zero (which is why I didn't think this was the problem). I decided to try setting all of the rp_filter values to zero and one or more of them did the trick.
If anyone has any advice for figuring out the minimum set of rp_filter values that must be zero, I would love to hear it.
In the "for what it's worth department" this was using an ike-2.1.7 rpm that was built from the FC-16 source rpm. I just downloaded the srpm and built it on my EL6 box using rpmbuild.
Cheers, Dave