Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[djm]

I have a DFL-210 and on its network a computer configured as an OpenVPN server.  I have set up the required Allow and NAT rules to allow remote clients to connect to the OpenVPN server.  All is working well as long as the OpenVPN clients only want to communicate with the OpenVPN server.

OpenVPN allows clients to communicate with other computers on the server's network as long as you can add a route to the servers gateway to pass all traffic from other computers to the OpenVPN link to the OpenVPN server.

My setup is:
ovpn server<-->   d-link<---->  another router<-->  ovpn client
(192.168.51.2)  (192.168.51.1)   (192.168.0.1)      (192.168.0.70)
(10.8.51.1)<---------------->              (10.8.51.6)

If I try to ping say 192.168.51.3 from 192.168.0.70 the log of the DLink router shows

Date    Severity        Category/ID     Rule                    Proto   Src/DstIf       Src/DstIP       Src/DstPort     Event/Action
2010-08-28
14:08:11    Warning    RULE
6000051    Default_Rule    ICMP    lan
   192.168.51.3
10.8.51.6    
   ruleset_drop_packet
drop
ipdatalen=64 icmptype=ECHO_REPLY echoid=44893 echoseq=3

So I then added some rules to allow traffic to go from 192.168.51.0/24 to 10.8.51.0/24 and visa versa.
On a ping attempt the logs change to

Date    Severity        Category/ID     Rule                    Proto   Src/DstIf       Src/DstIP       Src/DstPort     Event/Action
2010-08-28                   CONN                                                                                   192.168.51.3                         no_new_conn_for_this_packet
14:24:26        Warning 600013          LogOpenFails    ICMP    lan                  10.8.51.6                               drop

I'm not sure how to alleviate this and allow the new connections.  Does anyone have any suggestions?

[danilovav]

Your problem happens because 51.3 tries return packet thru default gateway (DFL), but DFL doesn't know anything about this connection.
There is three ways to fix your situation.

1) Move OVPN server to another subnet/interface on DFL.
By this way, all OVPN<->LAN packets will go thru DFL.

2) Make NAT OVPN->LAN on OVPN server.
By this way, OVPN clients will be masked by OVPN server address and all packets will go under subnet mask (without DFL).

3) Tune DFL to allow packets.
Add route for remote network (as i see, 10.8.510/24) thru OVPN server (192.168.51.2)
Add rule Foward fast lan/all-nets lan/all-nets (or two rules with specified networks)

[djm]

I think I have tried 3 already.

I added

Type      Interface      Network      Gateway      Local IP address      Metric      Monitor this route      Comments
 Route     lan     10.8.51.0/24     192.168.51.2         2    Yes    

192.168.51.2 is the OpenVPN server.

Is that what you meant?

With (2) do you mean to add a NAT rule?  Something like

     Allow_OpenVPN      NAT      lan      lannet      core      192.168.51.2      dns-all

Please let me know if I am on the wrong track with either/both of these.

Thanks,

David.

[danilovav]

_Route
Interface: lan
Network: 10.8.51.0/24
Gateway: 192.168.51.2
Metric: 2 (or 1)
Do not monitor route and change "local IP".

_IP rule
Your NAT rule is for port mapping, do not touch it.
You should make one more
Action: Forward fast
Service: all_services
Source: lan/all-nets
Destination: lan/all-nets

[djm]

The route I now have is:
Type      Interface      Network              Gateway              Local IP address      Metric      Monitor this route      Comments
 Route     lan            10.8.51.0/24     192.168.51.2    192.168.51.2              2            No

The extra rule is:
 OpenVPN_allow      FwdFast      lan      all-nets      lan      all-nets      all_services

But the log after an attempted ping is still the same:

Date     　Severity     　Category/ID     Rule  　　　　   Proto     Src/DstIf     Src/DstIP     Src/DstPort     Event/Action
2010-08-28 　Warning     CONN            LogOpenFails    ICMP    lan　   192.168.51.3   no_new_conn_for_this_packet
21:49:11　　　　　　　　　600013　　　　　　　　　　　　　　　　　　　　10.8.51.6    　　　　　　　　　　　　　　　drop
protocol=icmp ipdatalen=64 icmptype=ECHO_REPLY echoid=33907 echoseq=3

Any other suggestions?

[danilovav]

1) Clear "Local IP address" field in route

2) Did you maked "forward fast" rule?

[djm]

Cleared the "Local IP address" field in route.

If you look above I added a FastFwd rule:

OpenVPN_allow      FwdFast      lan      all-nets      lan      all-nets      all_services

Was that what you meant?

Still no ping response though.

[djm]

I've just noticed that if I try ssh-ing to the DLink router that the default_rule gets used (and drops packets).

i.e. ssh from 192.168.0.70 (alias 10.8.51.6) to 192.168.51.1

The log I get is:

Date         Severity     Category/ID     Rule                      Proto     Src/DstIf     Src/DstIP     Src/DstPort     Event/Action
2010-08-29    Warning     RULE             Default_Access_Rule    TCP      lan        10.8.51.6  51768                ruleset_drop_packet
11:37:41                            6000051                                                                             192.168.51.1   22                     drop
ipdatalen=40 tcphdrlen=40 syn=1

I'm not sure why the rule

2      OpenVPN_allow      Allow      any      10.8.51.0/24      any      192.168.51.0/24      all_services

wasn't used instead.

[danilovav]

In your rule change Allow to ForwardFast (i'm talking about it 3rd time!), make source/destination lan/all-nets lan/all-nets.

[djm]

Hi, if you look at my replies #4 and #6 I believe I already have what you suggest.

[djm]

I even tried making the ForwardFast rule the very first in the rule set.  Still no luck.

[danilovav]

Show your forward fast rule by screenshot.

[djm]

Screenshot of rule: http://www.flickr.com/photos/50857871@N04/4936954409/

[danilovav]

Try to ping, check log.
Also show routes.

[djm]

Route: http://www.flickr.com/photos/50857871@N04/4937658764/
Log from ping followed by ssh to DLink via OpenVPN: http://www.flickr.com/photos/50857871@N04/4937668322/