[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
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: "Aaron P. Martinez" <ml@xxxxxxxxxxxxxx>
  • Date: Mon, 31 Jan 2005 20:00:47 -0600

On Thu, 2005-01-27 at 10:17, James Hammer wrote:
> 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.

I didn't look at the kernel patch that you're using, but i did notice
that it seems relatively old.  I use sangoma cards in my linux
routers/firewalls and they come with an opensource(i think) driver
called wanpipe which will, when a connection goes down, bring down the
interface also.  This is very advantageous because you only have to have
a second route in place with a higher metric than your primary route and
when the primary goes down, (and the device must of course go down too)
it will pick up the secondary.  

You may want to have a look at the code and see if you can see how it's
doing that, but you have to know more than me because it's all jibberish
to me. lol

> >>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 ! -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 ! 
> -j SNAT --to $T1_IP
> If T1 is down: $BIN -I POSTROUTING -t nat -p udp --dport 5000 -d ! 
> -j SNAT --to $DSL_IP

wow, between the routing you have set up and the firewall mangling and
marking, that's a lot of work.  I'm sweating just looking at it.

> >>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.

Did this have any effect?

> >  
> >
> >>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
> >>up ./rem_network.up #route add -net netmask gw $5
> >>secret static.key
> >>#port 5000
> >>lport 5000
> >>rport 5000

probably won't make a bit of difference, but did you try it like:

ifconfig 5000
port 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.
I agree here, you're definitely losing security.  Have you tried using
the persist-tun option?  I think that normally it's used in the tls mode
for when the key regerates, but i don't see how it could hurt.

> 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