Hello all, I''ve recently configured and IPsec VPN between my OpenSUSE 10.2 router firewall running shorewall 3.4.4 and a friends Draytek Vigro 2930 ADSL modem/router/firewall. All is good other than my router can''t ping anything on my friends LAN, however machines on my LAN behind the firewall can ping machines on my friends firewall without problem. I''ve updated my policy file to be as follows: ############################################################################### #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT loc $FW ACCEPT $LOG loc vpn ACCEPT loc all REJECT $LOG $FW net ACCEPT $FW loc ACCEPT $LOG $FW vpn ACCEPT $FW all REJECT $LOG vpn loc ACCEPT vpn $FW ACCEPT net $FW DROP $LOG # THE FOLLOWING POLICY MUST BE LAST net loc DROP $LOG net vpn DROP net all DROP $LOG all all REJECT $LOG #LAST LINE -- DO NOT REMOVE So, I''ve allowed traffic from $FW to vpn and from vpn to $FW. Having looked at the documentation at www.shorewall.net that seems to be all I need to do. I can''t help thinking I must have missed something really obvious but if I have I can''t spot it. I''ve not updated any rules to allow specific types of traffic to/from the router. I understood that the policy should allow everything to/from the router to the vpn zone. Is that correct? Kind regards, Steve. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
lists wrote:> So, I''ve allowed traffic from $FW to vpn and from vpn to $FW. Having > looked at the documentation at www.shorewall.net that seems to be all I > need to do. I can''t help thinking I must have missed something really > obvious but if I have I can''t spot it. I''ve not updated any rules to > allow specific types of traffic to/from the router. I understood that > the policy should allow everything to/from the router to the vpn zone. > Is that correct? >This problem usually results from mis-configuration of IPSEC and has nothing to do with Shorewall. Does it work if you "shorewall clear" to remove Shorewall from the picture? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
lists@higgers.me.uk
2007-Dec-10 16:06 UTC
Re: Router A Unable to Connect to Router B on VPN
Quoting Tom Eastep <teastep@shorewall.net>:> lists wrote: > >> So, I''ve allowed traffic from $FW to vpn and from vpn to $FW. Having >> looked at the documentation at www.shorewall.net that seems to be all I >> need to do. I can''t help thinking I must have missed something really >> obvious but if I have I can''t spot it. I''ve not updated any rules to >> allow specific types of traffic to/from the router. I understood that >> the policy should allow everything to/from the router to the vpn zone. >> Is that correct? >> > > This problem usually results from mis-configuration of IPSEC and has nothing > to do with Shorewall. Does it work if you "shorewall clear" to remove > Shorewall from the picture?Yes, the problem still occurs after invoking "shorewall clear". I should have thought to try that myself. Thanks for the suggestion. I''ll dig further into the ipsec config docs. Thanks, Steve. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
lists@higgers.me.uk
2007-Dec-11 10:18 UTC
Re: Router A Unable to Connect to Router B on VPN
Quoting lists@higgers.me.uk:> Quoting Tom Eastep <teastep@shorewall.net>: > >> lists wrote: >> >>> So, I''ve allowed traffic from $FW to vpn and from vpn to $FW. Having >>> looked at the documentation at www.shorewall.net that seems to be all I >>> need to do. I can''t help thinking I must have missed something really >>> obvious but if I have I can''t spot it. I''ve not updated any rules to >>> allow specific types of traffic to/from the router. I understood that >>> the policy should allow everything to/from the router to the vpn zone. >>> Is that correct? >>> >> >> This problem usually results from mis-configuration of IPSEC and has nothing >> to do with Shorewall. Does it work if you "shorewall clear" to remove >> Shorewall from the picture? > > Yes, the problem still occurs after invoking "shorewall clear". I > should have thought to try that myself. Thanks for the suggestion. > > I''ll dig further into the ipsec config docs. >A follow up post to help anyone in the future searching the archives: I''ve since found that I can ping remote hosts on the VPN from my local router if I force the ping to use the internal NIC. So, "ping 192.168.1.1 -I eth0" works but "ping 192.168.1.1" doesn''t (eth0 is my internal NIC, eth2 is my external NIC.) I''ve tried updating my routing table to force requests for the remote LAN to be sent via eth0 instead of eth2 but this seems to kill the VPN entirely. The routing table looks like this: 1.2.3.0/24 dev eth2 proto kernel scope link src 1.2.3.4 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 192.168.1.0/24 via 1.2.3.1 dev eth2 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 1.2.3.1 dev eth2 Where: 1.2.3.4 is my public IP 1.2.3.1 is my ISP router at the other end of my ADSL line 192.168.0.0/24 is the local LAN 192.168.1.0/24 is the remote LAN eth0 is the internal interface eth2 is the external interface It seems that I need to force all packets that originate on the local router that are destined for the remote LAN to be sent via the internal NIC. Firstly, is this something that''s possible using shorewall? Secondly, is it a sensible approach to solving the problem? ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
lists@higgers.me.uk
2007-Dec-11 15:12 UTC
Re: Router A Unable to Connect to Router B on VPN
Quoting lists@higgers.me.uk:> Quoting lists@higgers.me.uk: > >> Quoting Tom Eastep <teastep@shorewall.net>: >> >>> lists wrote: >>> >>>> So, I''ve allowed traffic from $FW to vpn and from vpn to $FW. Having >>>> looked at the documentation at www.shorewall.net that seems to be all I >>>> need to do. I can''t help thinking I must have missed something really >>>> obvious but if I have I can''t spot it. I''ve not updated any rules to >>>> allow specific types of traffic to/from the router. I understood that >>>> the policy should allow everything to/from the router to the vpn zone. >>>> Is that correct? >>>> >>> >>> This problem usually results from mis-configuration of IPSEC and >>> has nothing >>> to do with Shorewall. Does it work if you "shorewall clear" to remove >>> Shorewall from the picture? >> >> Yes, the problem still occurs after invoking "shorewall clear". I >> should have thought to try that myself. Thanks for the suggestion. >> >> I''ll dig further into the ipsec config docs. >> > > A follow up post to help anyone in the future searching the archives: > > I''ve since found that I can ping remote hosts on the VPN from my local > router if I force the ping to use the internal NIC. So, "ping > 192.168.1.1 -I eth0" works but "ping 192.168.1.1" doesn''t (eth0 is my > internal NIC, eth2 is my external NIC.) > > I''ve tried updating my routing table to force requests for the remote > LAN to be sent via eth0 instead of eth2 but this seems to kill the VPN > entirely. > > The routing table looks like this: > > 1.2.3.0/24 dev eth2 proto kernel scope link src 1.2.3.4 > 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 > 192.168.1.0/24 via 1.2.3.1 dev eth2 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 > 169.254.0.0/16 dev eth0 scope link > 127.0.0.0/8 dev lo scope link > default via 1.2.3.1 dev eth2 > > Where: > 1.2.3.4 is my public IP > 1.2.3.1 is my ISP router at the other end of my ADSL line > 192.168.0.0/24 is the local LAN > 192.168.1.0/24 is the remote LAN > eth0 is the internal interface > eth2 is the external interface > > > It seems that I need to force all packets that originate on the local > router that are destined for the remote LAN to be sent via the > internal NIC. Firstly, is this something that''s possible using > shorewall? Secondly, is it a sensible approach to solving the problem? > >I tried to implement the rule described in the above paragraph using a REDIRECT rule but found that I always seemed to need to specify a port. I then tried a DNAT rule and succeeded in getting pings to the remote LAN (192.168.1.1) to be sent to the internal NIC but that simply resulted in pings to the remote LAN from the router being answered by the local NIC. That''s nearly what I want but seems to be rewriting the destination rather than rewriting the source. I then thought that I''d need to use an SNAT rule but the netmap file doesn''t allow me to specify source rewriting only for packets that originate on the router and are destined for the remote LAN. I want to leave packets that originate on the local LAN as they are since that part of the VPN works. Does anyone have any suggestions on how to implement the source rewriting rule? Thanks, Steve. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
lists@higgers.me.uk wrote: VPN> works. > > Does anyone have any suggestions on how to implement the source > rewriting rule? >Once again, _the proper way to fix this is in IPSEC, not in Shorewall_. In the Shorewall IPSEC article (http://www1.shorewall.net/IPSEC-2.6.html), you will find the eight (8) Security Policies that you need for full interaction between the two local networks and their gateways. If you do it that way, then you don''t have to resort to address rewriting hacks. If you really want to hack around it in Shorewall, then you need an entry in /etc/shorewall/masq to rewrite the source IP address in connections from the local external IP to the remote LAN. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
A follow up post for anyone searching the archives.
The solution was to add the line:
leftsourceip = 192.168.0.1
to the ipsec.conf file. This causes packets destined for the remote LAN
that originate on the local VPN endpoint to be sent from the internal
NIC and therefore sent through the VPN tunnel.
Regards,
Steve.
Tom Eastep wrote:> lists@higgers.me.uk wrote:
> VPN
>
>> works.
>>
>> Does anyone have any suggestions on how to implement the source
>> rewriting rule?
>>
>>
>
> Once again, _the proper way to fix this is in IPSEC, not in Shorewall_.
>
> In the Shorewall IPSEC article (http://www1.shorewall.net/IPSEC-2.6.html),
> you will find the eight (8) Security Policies that you need for full
> interaction between the two local networks and their gateways. If you do it
> that way, then you don''t have to resort to address rewriting
hacks.
>
> If you really want to hack around it in Shorewall, then you need an entry
in
> /etc/shorewall/masq to rewrite the source IP address in connections from
the
> local external IP to the remote LAN.
>
> -Tom
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It''s the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------------------------------------------------
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep
2007-Dec-21 16:19 UTC
Re: [SOLVED] Router A Unable to Connect to Router B on VPN
lists wrote:> A follow up post for anyone searching the archives. > > The solution was to add the line: > > leftsourceip = 192.168.0.1 > > to the ipsec.conf file. This causes packets destined for the remote LAN > that originate on the local VPN endpoint to be sent from the internal > NIC and therefore sent through the VPN tunnel. >Thanks for following up, Steve -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep
2007-Dec-21 18:37 UTC
Re: [SOLVED] Router A Unable to Connect to Router B on VPN
On Fri, 2007-12-21 at 08:19 -0800, Tom Eastep wrote:> lists wrote: > > A follow up post for anyone searching the archives. > > > > The solution was to add the line: > > > > leftsourceip = 192.168.0.1 > > > > to the ipsec.conf file. This causes packets destined for the remote LAN > > that originate on the local VPN endpoint to be sent from the internal > > NIC and therefore sent through the VPN tunnel. > > > > Thanks for following up, Steve >One final note. Specifying ''leftsourceip'' does not cause the packets ''..to be sent from the internal NIC''. It mearly causes them to have a source IP address of 192.168.0.1 which happens to be an IP address assigned to the internal NIC. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/