Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Mathias Jeschke]

Hi Jeff,

Jeff Boyce wrote:

> Thanks for the pointers.  I am doing some research now reading through
> the iptables man page and reading other examples.

I recommend this howto:

http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html

It was written for Linux 2.4, but all the iptables concepts are still valid.

HTH,
Mathias.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[J.Witvliet]

One small remark below:

-Original Message-
From: Bonno Bloksma [mailto:b.blok...@tio.nl] 
Sent: dinsdag 12 januari 2016 8:33
To: openvpn-users@lists.sourceforge.net
Subject: Re: [Openvpn-users] Issue getting to LAN behind VPN Server



# Set policies
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT



Why would you allow unrestricted outgoing traffic?
I would suggest to set also that policy to 'DROP', only allow what you expect, 
and allow in either direction statefull packages.

(just my 0.02 cents)

__
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Gert Doering]

Hi,

On Tue, Jan 12, 2016 at 01:41:09PM +0100, David Sommerseth wrote:
> > In the FORWARD chain, the easiest approach - and reasonably secure,
> > unless you distrust your VPN clients - is to permit everything
> > coming in via tun0
> > 
> > iptables -I INPUT -i tun0 -j FORWARD
> > 
> > (or similar to this, typing from memory)
> 
> I presume Gert meant:
> 
>  iptables -I FORWARD -i tun0 -j ACCEPT

Right.  Should drink more coffee before posting in the morning.

thanks,

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Bonno Bloksma]

Hi,

Ok, this getting away from OpenVPN so just this one reply.

> One small remark below:
>
> 
> 
>> # Set policies
>> $IPTABLES -P INPUT DROP
>> $IPTABLES -P FORWARD DROP
>> $IPTABLES -P OUTPUT ACCEPT
>> 
> 
> 
> Why would you allow unrestricted outgoing traffic?
> I would suggest to set also that policy to 'DROP',
> only allow what you expect, and allow in either direction statefull packages.

This is what I set up for small systems / sites, it is also perfect for private 
situations like my firewall/gateway at home. Remember OUTPUT is only what 
starts at the system itself. That can never be more then what is coming from 
the running services unless it is a workstation system. I have almost none of 
those, only Linux servers. But even then

The use of port filtering is greatly reduced nowadays where most applications 
simply use port 80 or 443 when they want to go outside and the default option 
is denied.
Or our larger sites I used to have a firewall with outbound ports listed and 
everything else would get denied. On those systems 90% percent of the traffic 
was port 80 and 443, and it wasn't only web traffic.
A few months ago we switched to Palo Alto firewalls which inspect the traffic 
and filter on that. I can now filter on for instance allow facebook traffic but 
deny facebook games. That level of filtering is "a bit more then we need" ;-) 
but it is nice to have.

Bonno Bloksma


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/16 08:50, Gert Doering wrote:
> Hi,
> 
> On Mon, Jan 11, 2016 at 01:06:18PM -0800, Jeff Boyce wrote:
>> Now, I don't want to leave my firewall with a default Accept All
>> setting on the forwarding chain, so I need to identify a rule
>> specific to the packet type / traffic that I want to allow.  I am
>> little less knowledgeable on firewall rules than routing so if
>> someone could provide a suggestion here I would appreciate it.  I
>> tried making a rule that allowed all UDP TUN traffic, but that
>> blocked my ping again.  I think then I tried adding a port
>> specific rule, but that didn't help either. At that point I ran
>> out of time to conduct any additional tests.
> 
> You need to allow UDP (for OpenVPN) in the INPUT chain, because
> that is consumed by the VPN server (-> INPUT), not forwarded
> elsewhere.
> 
> In the FORWARD chain, the easiest approach - and reasonably secure,
> unless you distrust your VPN clients - is to permit everything
> coming in via tun0
> 
> iptables -I INPUT -i tun0 -j FORWARD
> 
> (or similar to this, typing from memory)

I presume Gert meant:

 iptables -I FORWARD -i tun0 -j ACCEPT

This will allow traffic coming in on tun0 to be forwarded anywhere.
It will not enable access to the this particular host.  For that you
need to modify the INPUT chain.

To allow hosts on this box's network to access hosts on the tun0
"net", you must add:

 iptables -I FORWARD -o tun0 -j ACCEPT

This allows forwarded packets to exit on the tun0 device.


- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlaU9GQACgkQDC186MBRfrqpzACgqp3BwlXiYwoxGAodLH/IHyU7
YesAmwSEXMl/SWPl1i6LMe79AiGJrgUP
=oSyC
-END PGP SIGNATURE-

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

On 1/11/2016 1:49 PM, Jan Just Keijser wrote:
> Hi Jeff,
>
> On 11/01/16 22:06, Jeff Boyce wrote:
>> My additional diagnostic testing results are at the bottom.
>>
> my comments are also at the bottom ;)
>
>> On 1/6/2016 11:38 AM, Morten Christensen wrote:
>>> Den 05-01-2016 kl. 19:34 skrev Jeff Boyce:
 Greetings -

 I have a detailed description of my issue posted over on the Forum, 
 but
 am not getting any responses.

 My issue description is posted at
 https://forums.openvpn.net/topic20369.html.

 I believe that my problem is a routing issue, but I have exhausted my
 avenues of research and knowledge.  I am hoping someone with an eye 
 for
 routing issues might be able to spot where my issue is located and 
 offer
 a recommendation.
>>> I have looked at your forum description.
>>> You have good chances to be on the wrong list. This looks like routing
>>> problems between your other servers and their default gateway.
>>>
>>> What happens when you try a traceroute from the other server .53 to
>>> the vpn-servers tunnel ip 10.9.8.1 ?
>>>
>>> Have you considered starting with the simple solution no. 3, and if
>>> that works go on with no. 4 ?
>>>
>>> -- 
>>> Morten Christensen
>>>
>>>
>> I started with the easiest tests first.  Selva had recommended that I
>> verify that the Windows client received and properly setup the pushed
>> route to the 192.168.112.0/24 subnet.  The routing table on the Windows
>> client before and after establishing the VPN connection is listed below.
>>
>> *Before VPN Connection (Windows client route print)*
>> IPv4 Route Table
>> === 
>>
>> Active Routes:
>> Network Destination Netmask Gateway Interface Metric
>> 0.0.0.0 0.0.0.0 192.168.123.2 192.168.123.111 10
>> 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
>> 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
>> 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 192.168.56.0 255.255.255.0 On-link 192.168.56.1 276
>> 192.168.56.1 255.255.255.255 On-link 192.168.56.1 276
>> 192.168.56.255 255.255.255.255 On-link 192.168.56.1 276
>> 192.168.123.0 255.255.255.0 On-link 192.168.123.111 266
>> 192.168.123.111 255.255.255.255 On-link 192.168.123.111 266
>> 192.168.123.255 255.255.255.255 On-link 192.168.123.111 266
>> 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
>> 224.0.0.0 240.0.0.0 On-link 192.168.56.1 276
>> 224.0.0.0 240.0.0.0 On-link 192.168.123.111 266
>> 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 255.255.255.255 255.255.255.255 On-link 192.168.56.1 276
>> 255.255.255.255 255.255.255.255 On-link 192.168.123.111 266
>> === 
>>
>> Persistent Routes:
>> Network Address Netmask Gateway Address Metric
>> 0.0.0.0 0.0.0.0 192.168.123.2 Default
>> === 
>>
>>
>> *After VPN Connection (Windows client route print)*
>> C:\>ipconfig
>>
>> Ethernet adapter Local Area Connection 2:
>>
>> Connection-specific DNS Suffix . :
>> Link-local IPv6 Address . . . . . : fe80::44cc:5041:5d8d:ae76%9
>> IPv4 Address. . . . . . . . . . . : 10.9.8.6
>> Subnet Mask . . . . . . . . . . . : 255.255.255.252
>> Default Gateway . . . . . . . . . :
>>
>>
>>   > added routes
>> IPv4 Route Table
>> === 
>>
>> Active Routes:
>> Network Destination Netmask Gateway Interface Metric
>> 0.0.0.0 0.0.0.0 192.168.123.2 192.168.123.111 10
>>   > 10.9.8.1 255.255.255.255 10.9.8.5 10.9.8.6 31
>>   > 10.9.8.4 255.255.255.252 On-link 10.9.8.6 286
>>   > 10.9.8.6 255.255.255.255 On-link 10.9.8.6 286
>>   > 10.9.8.7 255.255.255.255 On-link 10.9.8.6 286
>> 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
>> 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
>> 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 192.168.56.0 255.255.255.0 On-link 192.168.56.1 276
>> 192.168.56.1 255.255.255.255 On-link 192.168.56.1 276
>> 192.168.56.255 255.255.255.255 On-link 192.168.56.1 276
>>   > 192.168.112.0 255.255.255.0 10.9.8.5 10.9.8.6 31
>> 192.168.123.0 255.255.255.0 On-link 192.168.123.111 266
>> 192.168.123.111 255.255.255.255 On-link 192.168.123.111 266
>> 192.168.123.255 255.255.255.255 On-link 192.168.123.111 266
>> 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
>> 224.0.0.0 240.0.0.0 On-link 192.168.56.1 276
>> 224.0.0.0 240.0.0.0 On-link 192.168.123.111 266
>>   > 224.0.0.0 240.0.0.0 On-link 10.9.8.6 286
>> 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 255.255.255.255 255.255.255.255 On-link 192.168.56.1 276
>> 255.255.255.255 255.255.255.255 On-link 192.168.123.111 266
>>   > 255.255.255.255 255.255.255.255 On-link 10.9.8.6 286
>> === 
>>
>> Persistent Routes:
>> Network Address Netmask Gateway Address Metric
>> 0.0.0.0 0.0.0.0 192.168.123.2 Default
>> 

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Gert Doering]

Hi,

On Mon, Jan 11, 2016 at 01:06:18PM -0800, Jeff Boyce wrote:
> Now, I don't want to leave my firewall with a default Accept All setting 
> on the forwarding chain, so I need to identify a rule specific to the 
> packet type / traffic that I want to allow.  I am little less 
> knowledgeable on firewall rules than routing so if someone could provide 
> a suggestion here I would appreciate it.  I tried making a rule that 
> allowed all UDP TUN traffic, but that blocked my ping again.  I think 
> then I tried adding a port specific rule, but that didn't help either.  
> At that point I ran out of time to conduct any additional tests.

You need to allow UDP (for OpenVPN) in the INPUT chain, because that
is consumed by the VPN server (-> INPUT), not forwarded elsewhere.

In the FORWARD chain, the easiest approach - and reasonably secure, unless
you distrust your VPN clients - is to permit everything coming in via
tun0

   iptables -I INPUT -i tun0 -j FORWARD

(or similar to this, typing from memory)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Bonno Bloksma]

Hi,

[...]

>>> If someone can point me in the right direction to create a specific 
>>> firewall rule for the forward chain I would be grateful.  My thoughts 
[...]
>>>
>> If you want to allow all traffic to and from the tun network(s) to be 
>> forwarded then add something like
>>
>>   iptables -A FORWARD -i tun+ -j ACCEPT
>>   iptables -A FORWARD -o tun+ -j ACCEPT
>>
>> remember that when forwarding traffic you need to write rules for both 
>> incoming and outgoing traffic.
>>
>> HTH,
>>
>> JJK
>>


> Thanks for the pointers.  I am doing some research now reading through
> the iptables man page and reading other examples.  I suspect that my
> initial forwarding rule attempt was lacking because I was only addressing
> one direction and not the bi-directional nature of forwarding. 
> If I have some time this evening I will give this a try.
> Thanks.
> 
> Jeff

For me a typical iptables firewall looks like this. In this case ALL outbound 
traffic from the box, and the internal network, is allowed.
I use some variables to have the stuff that can change at the top.

KEEPSTATE=" -m state --state ESTABLISHED,RELATED"
WORLD_NET=0.0.0.0/0
IPTABLES=/sbin/iptables

# If NAT is needed...
WORLD_IF=eth0
WORLD_NAT=false

# Set policies
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT

# Flush all rules in all chains and then delete all chains
chains=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $chains; do $IPTABLES -t $i -F; done
for i in $chains; do $IPTABLES -t $i -X; done
# Reset all counters for default chains
$IPTABLES -Z

# Accept return traffic.
$IPTABLES -A FORWARD -j ACCEPT $KEEPSTATE
$IPTABLES -A INPUT -j ACCEPT $KEEPSTATE

# SSH allowed
$IPTABLES -A INPUT -s $WORLD_NET -p TCP --dport ssh -j ACCEPT

# Loopback interface allow all
$IPTABLES -A INPUT -i lo -j ACCEPT

# We accept ping etc
$IPTABLES -A INPUT -p icmp -j ACCEPT

if [ $WORLD_NAT = true ] ; then
  $IPTABLES --table nat -A POSTROUTING -o $WORLD_IF -j MASQUERADE
fi


In here the "Accept return traffic" rules cover the return traffic so I only 
have to worry about the outgoing stuff in my other rules.
For OpenVPN I need to add just a few more rules:


# OpenVPN allowed (UDP and TCP)
$IPTABLES -A INPUT -s $WORLD_NET -p UDP --dport openvpn -j ACCEPT
$IPTABLES -A INPUT -s $WORLD_NET -p TCP --dport openvpn -j ACCEPT

# Allow all traffic to the tunnel
$IPTABLES -A FORWARD -i tun+ -j ACCEPT


In my case the return traffic is covered as we still accept all established and 
related traffic.
But the second line from Jan
$IPTABLES -A FORWARD -o tun+ -j ACCEPT
Covers that a bit more explicitly.

This is my basic firewall rule set for a "simple" Linux box acting sometimes as 
a router if no additional filters are needed for outbound traffic.


Bonno Bloksma


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

Apparently this was originally sent in html format, and thus not posted 
to the list.
Comments at bottom.


On 1/6/2016 2:15 PM, Dreetjeh D wrote:
> Hello,
>
> Posted to the forum but that takes some time :-)
>
> I`m somewhat newbie so forgive me beforehand...
>
> When I compare your server config with mine then I don`t see a route 
> to the tunnel wich in my config is present.
> push "route 10.9.8.0 255.255.255.0" (for your case)
>
> But maybe that is too simple :)
>
> Greeting Pippin
>
>
> > Date: Wed, 6 Jan 2016 12:04:19 -0800
> > From: jbo...@meridianenv.com
> > To: openvpn-users@lists.sourceforge.net
> > Subject: Re: [Openvpn-users] Issue getting to LAN behind VPN Server
> >
> >
> >
> > On 1/6/2016 11:38 AM, Morten Christensen wrote:
> > >
> > > Den 05-01-2016 kl. 19:34 skrev Jeff Boyce:
> > >> Greetings -
> > >>
> > >> I have a detailed description of my issue posted over on the 
> Forum, but
> > >> am not getting any responses.
> > >>
> > >> My issue description is posted at
> > >> https://forums.openvpn.net/topic20369.html.
> > >>
> > >> I believe that my problem is a routing issue, but I have exhausted my
> > >> avenues of research and knowledge. I am hoping someone with an 
> eye for
> > >> routing issues might be able to spot where my issue is located 
> and offer
> > >> a recommendation.
> > >
> > > I have looked at your forum description.
> > > You have good chances to be on the wrong list. This looks like 
> routing
> > > problems between your other servers and their default gateway.
> > >
> > I tend to agree, that I think this is a routing problem. But the
> > problem only occurs trying to access the other servers through the VPN,
> > otherwise the other servers do not appear to have any routing or 
> default
> > gateway problem. And since many of the issue discussed on this list are
> > routing related, this seemed like the most appropriate place to discuss
> > it. I am not aware of another list that might be more applicable.
> >
> > > What happens when you try a traceroute from the other server .53 to
> > > the vpn-servers tunnel ip 10.9.8.1 ?
> > >
> > Ah, good question and something else that I can test and get feedback
> > that might help diagnose this better. I will try when I make a
> > connection from the remote end tonight.
> >
> > > Have you considered starting with the simple solution no. 3, and if
> > > that works go on with no. 4 ?
> > >
> > I have considered it, yes. But while solution #3 may seem simple to
> > some people, it seems more confusing to me. My comfort level with
> > iptables is even less than my knowledge of routing. So I don't think I
> > would really solve my problem, as much as just switch what problem I am
> > working on. Thanks for your input, it is appreciated as you have given
> > me something physical to test.
> >
> > > --
> > > Morten Christensen
> > >
> > >

Thanks to Morten, debbie10t, Selva, and Gert for your suggestions on 
additional diagnostic tests that I can perform.  I have a list of things 
to check from both sides of the tunnel that will certainly educate me, 
and should help pinpoint my issue.  However, I have run into a little 
scheduling problem and it may take me a few days before I can get to all 
of this.  I will post again after I have completed all the suggestions.  
Thanks.

Jeff

-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com




--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

  
  
Comments at bottom.


On 1/6/2016 2:15 PM, Dreetjeh D wrote:


  
  Hello,
 
Posted to the forum but that takes some time :-)
 
I`m somewhat newbie so forgive me beforehand...
 
When I compare your server config with mine then I don`t see
a route to the tunnel wich in my config is present.
push "route 10.9.8.0 255.255.255.0" (for your case)
 
But maybe that is too simple :)
 
Greeting Pippin

 
> Date: Wed, 6 Jan 2016 12:04:19 -0800
  > From: jbo...@meridianenv.com
  > To: openvpn-users@lists.sourceforge.net
          > Subject: Re: [Openvpn-users] Issue getting to LAN behind
  VPN Server
  > 
  > 
  > 
  > On 1/6/2016 11:38 AM, Morten Christensen wrote:
  > >
  > > Den 05-01-2016 kl. 19:34 skrev Jeff Boyce:
  > >> Greetings -
  > >>
  > >> I have a detailed description of my issue posted
  over on the Forum, but
  > >> am not getting any responses.
  > >>
  > >> My issue description is posted at
  > >> https://forums.openvpn.net/topic20369.html.
  > >>
  > >> I believe that my problem is a routing issue,
  but I have exhausted my
  > >> avenues of research and knowledge. I am hoping
  someone with an eye for
  > >> routing issues might be able to spot where my
  issue is located and offer
  > >> a recommendation.
  > >
  > > I have looked at your forum description.
  > > You have good chances to be on the wrong list. This
  looks like routing 
  > > problems between your other servers and their
  default gateway.
  > >
  > I tend to agree, that I think this is a routing problem.
  But the 
  > problem only occurs trying to access the other servers
  through the VPN, 
  > otherwise the other servers do not appear to have any
  routing or default 
  > gateway problem. And since many of the issue discussed on
  this list are 
  > routing related, this seemed like the most appropriate
  place to discuss 
  > it. I am not aware of another list that might be more
  applicable.
  > 
  > > What happens when you try a traceroute from the
  other server .53 to 
  > > the vpn-servers tunnel ip 10.9.8.1 ?
  > >
  > Ah, good question and something else that I can test and
  get feedback 
  > that might help diagnose this better. I will try when I
  make a 
  > connection from the remote end tonight.
  > 
  > > Have you considered starting with the simple
  solution no. 3, and if 
  > > that works go on with no. 4 ?
  > >
  > I have considered it, yes. But while solution #3 may seem
  simple to 
  > some people, it seems more confusing to me. My comfort
  level with 
  > iptables is even less than my knowledge of routing. So I
  don't think I 
  > would really solve my problem, as much as just switch
  what problem I am 
  > working on. Thanks for your input, it is appreciated as
  you have given 
  > me something physical to test.
  > 
  > > -- 
  > > Morten Christensen
  > >
  > >

  


Thanks to Morten, debbie10t, Selva, and Gert for your suggestions on
additional diagnostic tests that I can perform.  I have a list of
things to check from both sides of the tunnel that will certainly
educate me, and should help pinpoint my issue.  However, I have run
into a little scheduling problem and it may take me a few days
before I can get to all of this.  I will post again after I have
completed all the suggestions.  Thanks.

Jeff
-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com
  


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[J.Witvliet]

Hi Jeff,

When I was reading your message. Two possibilities came up:
a) smaller subnets take precedence over larger subnets, which can cause all 
sorts of undesirable effects when you have overlapping networks (though not 
appropriate in your case, I think)
b) conflict between routes pushed by dhcp and openvpn. If the dhcp-lease time 
is short, it two can have all sorts of "funny effects"
Next I just had a quick glance on the mentioned url

What caught my attention was this:
On the VPN-server you have this line:
push "route 192.168.112.0 255.255.255.0"

While your machine has  this LAN config:
[root@sequoia ~]# ifconfig
eth0  Link encap:Ethernet  HWaddr aa:bb:00:9D:B2:49
  inet addr:192.168.112.50  Bcast:192.168.112.255 Mask:255.255.255.0


You might have a conflict there



-Original Message-
From: Jeff Boyce [mailto:jbo...@meridianenv.com] 
Sent: dinsdag 5 januari 2016 19:35
To: openvpn-users@lists.sourceforge.net
Subject: [Openvpn-users] Issue getting to LAN behind VPN Server

Greetings -

I have a detailed description of my issue posted over on the Forum, but am not 
getting any responses.  A few reads over the course of several weeks, but no 
responses.  I posted it to the Forum after someone on the list here suggested 
the Forum might be a better place for assistance.  
But alas, it appears to me that this list gets more traffic and has a more 
knowledgeable base of helpers, so I am coming back to this list with my request.

My issue description is posted at
https://forums.openvpn.net/topic20369.html.

I believe that my problem is a routing issue, but I have exhausted my avenues 
of research and knowledge.  I am hoping someone with an eye for routing issues 
might be able to spot where my issue is located and offer a recommendation.  
Any responses can be directed to either the Forum or here at the mailing list, 
as I am now subscribed to the Forum and have been on the mailing list for 
years.  You may cc me directly with responses to the mailing list as I am only 
subscribed to the daily digest.  Thanks.

-- 

Jeff Boyce
Meridian Environmental
www.meridianenv.com


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

__
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.

--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

Thanks for taking the time to review this.  I know there is a lot of 
information, and that puts off a lot of people, but I find it helps most 
people understand the issue and see that I have done my homework.  
Additional comments in-line below.


On 1/5/2016 3:24 PM, debbie...@gmail.com wrote:
> Hi Jeff,
>
> as you put so much work into your post on the forum I did not
> want to hit you with an "off the cuff" answer ...
> but I can, at least, see more clearly your situation.
>
> Also, it seems to me, you have all the necessary tools and knowhow
> to implement the solution yourself .. which you have .. more or less ..
> ie: a "fully routed" solution .. which you claim does not work ?
>
> Quote:
> I added a static route on my default gateway (a PfSense box) to redirect
> any VPN network traffic back to the VPN box, which I believe should 
> send it
> back through the tunnel to the point of origin. However, this did not
> resolve my issue, so I must be mistaken about my routing somewhere, or 
> there
> is something else that I have not considered
>
> What you have not considered is .. pfsense .. we do not support it.
>
> As I have had a similar issues with different routers (and pfsense)
> I will add this as a pointer:
>
> Not all /routers or Operating Systems/ are created equal.
> RFC compliancy is extremely optional ..
>
> Check all your Vendor's documentation ..
> Run a packet sniffer to verify their often bold and inaccurate claims ..
> (Example:
> http://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/
>  
>
> )
>
> The point being:
> Check you have "ICMP redirect support" throughout.
>
I am not familiar with ICMP redirect support.  I will have to do some 
more research and education to familiarize myself with this to 
understand how it might apply in my situation.

> Otherwise, add the routes to the clients that need it .. manually
> or from some other central configuration system.
>
This might be my plan of last resort, because I think it is going to 
confuse me more.

> Just my2c .. it worked for me.
>
> Note: OpenVPN cannot help with your routers etc
> Note: ICMP redirect is often considered to be a security risk!
>
> PS: You did not include any logs on your forum post ..
> and .. as (*currently) I am helping mod the forum
> I am currently holding off a misguided reply
> which has been offered to your forum question.
> Presumably you would prefer to add the logs
> of a connection which *does not work* as expected .. first ;)
>
I did not add any logs because there is nothing in the logs relating to 
getting to a client behind the VPN server (I will double check this 
again).  As I mentioned I have a solid connection from the remote client 
to the VPN server, and my logs show that.  But when I try to ping or 
connect to a box on the LAN subnet (other than the VPN server) there is 
no information in the VPN logs that shows a ping failure.  The error I 
get is at the console specifying the destination host is unreachable.  
If there is some specific information that might be in a specific log 
file I can provide it, but I don't know what to look for or what to 
provide that shows it *does not work* as expected.  Clues gladly accepted.

>
> Enjoy the journey .. the destination maybe disappointing ;)
>
I do enjoy the journey; but I do hope the destination is not disappointing.

-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

  
  


On 1/5/2016 8:28 PM, Selva Nair wrote:


  

  On Tue, Jan 5, 2016 at 1:34 PM, Jeff
Boyce 
wrote:

  My issue description is posted at
  https://forums.openvpn.net/topic20369.html.
  
  I believe that my problem is a routing issue, but I have
  exhausted my
  avenues of research and knowledge. 
  
  
  The configs and routes on server & router look fine, but
  not clear whether the windows box (client) has correctly set
  up the pushed route to the 192.168.112.0/24
  subnet. Please check the routing table on the windows client.
  

That is something that I can check into tonight.  Considering the
things that I have seen and heard about how Windows handles routing,
I see that might be a possibility.  The remote client is a Vista box
after all.

  
 By the way, do you need "route-method
  exe"? Leaving it out to let openvpn choose the best method may
  be better.


  

I know historically that I needed that on some clients, and I have
been rolling this standard config into other clients.  Maybe things
have changed (in Windows or OpenVPN) now that it is not necessary. 
I will look into that.  Thanks.

  
Selva


  


-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com
  


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

Thanks for the review and comments.  My notes interspersed below.

On 1/6/2016 1:31 AM, j.witvl...@mindef.nl wrote:
> Hi Jeff,
>
> When I was reading your message. Two possibilities came up:
> a) smaller subnets take precedence over larger subnets, which can cause all 
> sorts of undesirable effects when you have overlapping networks (though not 
> appropriate in your case, I think)
I don't think I have any overlapping networks.  The VPN server LAN is 
192.168.112.xx, while the remote client LAN is 192.168.123.xx.

> b) conflict between routes pushed by dhcp and openvpn. If the dhcp-lease time 
> is short, it two can have all sorts of "funny effects"
Interesting thought I hadn't heard of before.  I will have to do a 
little research and educating myself on this topic.  I am running 
dnsmasq on my VPN server LAN.  Most of the desktops get a set IP from 
the DHCP server where the lease time is specified as infinite. The other 
servers in the LAN have fixed IPs and are not DHCP enabled.  So in that 
respect the DHCP environment in the LAN is mixed.

> Next I just had a quick glance on the mentioned url
>
> What caught my attention was this:
> On the VPN-server you have this line:
> push "route 192.168.112.0 255.255.255.0"
>
> While your machine has  this LAN config:
> [root@sequoia ~]# ifconfig
> eth0  Link encap:Ethernet  HWaddr aa:bb:00:9D:B2:49
>inet addr:192.168.112.50  Bcast:192.168.112.255 Mask:255.255.255.0
> 
>
> You might have a conflict there
I am going to need more explanation here, as I am not sure what you are 
describing.  Showing the limits of my routing knowledge.  I appreciate 
the feedback.


-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Morten Christensen]

Den 05-01-2016 kl. 19:34 skrev Jeff Boyce:
> Greetings -
>
> I have a detailed description of my issue posted over on the Forum, but
> am not getting any responses.
>
> My issue description is posted at
> https://forums.openvpn.net/topic20369.html.
>
> I believe that my problem is a routing issue, but I have exhausted my
> avenues of research and knowledge.  I am hoping someone with an eye for
> routing issues might be able to spot where my issue is located and offer
> a recommendation.

I have looked at your forum description.
You have good chances to be on the wrong list. This looks like routing 
problems between your other servers and their default gateway.

What happens when you try a traceroute from the other server .53 to the 
vpn-servers tunnel ip 10.9.8.1 ?

Have you considered starting with the simple solution no. 3, and if that 
works go on with no. 4 ?

--
Morten Christensen


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Jeff Boyce]

On 1/6/2016 11:38 AM, Morten Christensen wrote:
>
> Den 05-01-2016 kl. 19:34 skrev Jeff Boyce:
>> Greetings -
>>
>> I have a detailed description of my issue posted over on the Forum, but
>> am not getting any responses.
>>
>> My issue description is posted at
>> https://forums.openvpn.net/topic20369.html.
>>
>> I believe that my problem is a routing issue, but I have exhausted my
>> avenues of research and knowledge.  I am hoping someone with an eye for
>> routing issues might be able to spot where my issue is located and offer
>> a recommendation.
>
> I have looked at your forum description.
> You have good chances to be on the wrong list. This looks like routing 
> problems between your other servers and their default gateway.
>
I tend to agree, that I think this is a routing problem.  But the 
problem only occurs trying to access the other servers through the VPN, 
otherwise the other servers do not appear to have any routing or default 
gateway problem.  And since many of the issue discussed on this list are 
routing related, this seemed like the most appropriate place to discuss 
it.  I am not aware of another list that might be more applicable.

> What happens when you try a traceroute from the other server .53 to 
> the vpn-servers tunnel ip 10.9.8.1 ?
>
Ah, good question and something else that I can test and get feedback 
that might help diagnose this better.  I will try when I make a 
connection from the remote end tonight.

> Have you considered starting with the simple solution no. 3, and if 
> that works go on with no. 4 ?
>
I have considered it, yes.  But while solution #3 may seem simple to 
some people, it seems more confusing to me.  My comfort level with 
iptables is even less than my knowledge of routing.  So I don't think I 
would really solve my problem, as much as just switch what problem I am 
working on.  Thanks for your input, it is appreciated as you have given 
me something physical to test.

> -- 
> Morten Christensen
>
>

-- 

Jeff Boyce, CF
Meridian Environmental
2136 Westlake Ave. North
Seattle, WA  98109
206-522-8282
www.meridianenv.com


--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Morten Christensen]

Den 06-01-2016 kl. 10:31 skrev j.witvl...@mindef.nl:
> Hi Jeff,
>
> When I was reading your message. Two possibilities came up:
> a) smaller subnets take precedence over larger subnets, which can cause all 
> sorts of undesirable effects when you have overlapping networks (though not 
> appropriate in your case, I think)
> b) conflict between routes pushed by dhcp and openvpn. If the dhcp-lease time 
> is short, it two can have all sorts of "funny effects"
> Next I just had a quick glance on the mentioned url
>
> What caught my attention was this:
> On the VPN-server you have this line:
> push "route 192.168.112.0 255.255.255.0"
>
> While your machine has  this LAN config:
> [root@sequoia ~]# ifconfig
> eth0  Link encap:Ethernet  HWaddr aa:bb:00:9D:B2:49
>inet addr:192.168.112.50  Bcast:192.168.112.255 Mask:255.255.255.0
> 
>
> You might have a conflict there
I cannot see a conflict in that.
The server tells the client, that the server-LAN is to be routed through 
the tunnel.
Looks to me like the basic setup in all OpenVPN config's.

--
Morten Christensen

--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Issue getting to LAN behind VPN Server

[Selva Nair]

On Tue, Jan 5, 2016 at 1:34 PM, Jeff Boyce  wrote:

>
> My issue description is posted at
> https://forums.openvpn.net/topic20369.html.
>
> I believe that my problem is a routing issue, but I have exhausted my
> avenues of research and knowledge.


The configs and routes on server & router look fine, but not clear whether
the windows box (client) has correctly set up the pushed route to the
192.168.112.0/24 subnet. Please check the routing table on the windows
client. By the way, do you need "route-method exe"? Leaving it out to let
openvpn choose the best method may be better.

Selva
--
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users