[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] unwanted change to reply port causing "Incoming packet rejected" error


  • Subject: Re: [Openvpn-users] unwanted change to reply port causing "Incoming packet rejected" error
  • From: James Hammer <openvpn@xxxxxxxxxxx>
  • Date: Thu, 27 Jan 2005 15:11:46 -0600

Aaron P. Martinez wrote:

On Tue, 2005-01-25 at 16:08, James Hammer wrote:


We have openvpn setup on a linux router with 2 external interfaces (a T1 and a DSL line for failover)


What are you using to do the load balancing? creating a virtual device
w/teql or some other method, specifics?


The tricky part is that it is not true load balancing. In the project description I was given, certain types of traffic were to go out a specific interface all the time. If that interface were to go down then that specific traffic should be switched over to the interface that is up. For example, we route all http traffic over the DSL line. If the DSL line goes down we route it over the T1. So the desired effect is mostly failover, not load balancing.

I setup failover using only the Julian Anastasov kernel patch, ip rules, and a firewall according to the outline in http://www.ssi.bg/~ja/nano.txt. No virtual devices were created. I just setup the routing tables and the Anastasov kernel patch handles the rest. I do use keepalived to detect when a route goes down. Keepalived can then run an external script to handle changes to the routing table.

The basic idea is to setup a separate routing table for each interface. In the firewall if traffic meets a certain criteria it is given a certain fwmark. Using this fwmark I then send the traffic out the appropriate interface using an ip rule. If traffic is not marked by the firewall then it reaches a default table which does load balance the traffic over the two interfaces.

Here is how the rules and routing are setup:

<snip>

# ip route show table 201
default via $T1GATEWAY dev eth2  proto static  src $T1IP
prohibit default  proto static  metric 1

# ip route show table 202
default via $DSLGATEWAY dev eth1  proto static  src $DSLIP
prohibit default  proto static  metric 10

# ip route show table 222
default  proto static
      nexthop via $T1GATEWAY  dev eth2 weight 1
      nexthop via $DSLGATEWAY dev eth1 weight 1

# ip rule show:

0:      from all lookup local
50:     from all lookup main
100:    from all fwmark 0x2 lookup 202
101:    from all fwmark 0x2 lookup 201
110:    from all fwmark 0x3 lookup 201
111:    from all fwmark 0x3 lookup 202
201:    from $T1NETWORK lookup 201
202:    from $DSLNETWORK lookup 202
222:    from all lookup 222
32766:  from all lookup main
32767:  from all lookup default
<snip>

I quote here from http://www.ssi.bg/~ja/nano.txt:

"Table local is used for the local loopback, table main has the network
routes to the internal network and for the external interfaces, which
only give access to our gateways. Tables 201 and 202 (which also might
have the same priority), will provide a default route if the local
source address is known (because they have to match NWE1 or NWE2). And
table 222 will provide the multipath route. The tables with priority
32766 and 32767 will not be used."

In addition I am using the fwmark rules to send the specifically marked traffic out the given interface. The order of the rules is important. Let's say the T1 were to go down. Rule 110 would automatically be removed so that now traffic marked with fwmark 0x2 and 0x3 will go to table 202 which is the DSL. The kernel patch also makes it so that any traffic that hits table 222 will know that the T1 is down and will be sent over the DSL route.

and 1 internal interface. iproute2 and iptables are used to force the vpn traffic over the T1.



These configs might help. Do you have anything in your iptables either
in the filtering or in the nat (post or prerouting) tables that uses
port 1025? specifically snats


Nothing is set to specifically use port 1025 in snats or otherwise (or any of the other ports it has changed to such as 1024 and 1026).

Here are pre and postrouting for the VPN.

# Mark traffic bound for T1 by default
$BIN -A PREROUTING -t mangle -p udp --dport 5000 -j MARK --set-mark 3
$BIN -t mangle -A OUTPUT -p udp --dport 5000 -d ! 192.168.1.0/24 -j MARK --set-mark 3


Then, depending on the state of the T1 the following is also set:

If T1 is up: $BIN -I POSTROUTING -t nat -p udp --dport 5000 -d ! 192.168.1.0/24 -j SNAT --to $T1_IP
If T1 is down: $BIN -I POSTROUTING -t nat -p udp --dport 5000 -d ! 192.168.1.0/24 -j SNAT --to $DSL_IP



Looking at the log file on the remote openvpn server I see the following:

<snip>
Jan 12 15:40:30 [openvpn] NOTE: Incoming packet rejected from xxx.xxx.xxx.xxx:1025[2], expected peer address: xxx.xxx.xxx.xxx:5000



are the xxx addresses the same in the rejected from and the expected
from error?


Yes.  They are the same.  The only thing that changes is the port.

Have you thought about using a current version, even to the current
stable of 1.6. Testing with the 2.0 branch? you could run them
simultaneously to see if it happens to both at the same time.


That is a good suggestion.  I will give that a try.

Here are some of the configs on the two openvpn servers:

Local (the one with the problem):

dev tun
remote yyy.yyy.yyy.yyy
ifconfig 192.168.0.1 192.168.0.2
up ./rem_network.up #route add -net 192.168.22.0 netmask 255.255.255.0 gw $5
secret static.key
#port 5000
lport 5000
rport 5000



why not use standard port or leave it commented out here as 5000 is
default for this version and you're using the same for both incoming and
outgoing?


This is a good suggestion and I have switched it back. I had read in the man page that 'port' should handle both the local and remote ports but since the local port was changing I thought I would give it a try. It had no effect though.

I will mention that setting the 'float' option in conjunction with the 'remote' option does keep the tunnel up and working. However, it seems that I am loosing a layer of security in doing that because it is no longer locked down to a single IP/Port pair.

Again, it works on port 5000 if only the T1 is up and DSL is down. It switches between port 5000 and another port if the T1 and DSL are up.

Thanks for your response and help!

--
James Hammer

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