Issue With NAT and Multiple WAN Interfaces - Vyatta

22/4/2014
Issue with NAT and multiple WAN interfaces | Vyatta.org Community
Vyatta.com(http://vyatta.com/)
Support Center (http://www2.vyatta.com/support)
Vyatta.orgCommunity
Search
GETTING STARTED
SUPPORT & SERVICES
DOWNLOADS
COM M UNITY
DOCUM ENTATION
CONTRIBUTE
FORUM S
IssuewithNATandmultipleWANinterfaces
Log in or register to post comments
Last post
11 posts / 0 new
Fri, 12/17/2010 06:52
#1
Singularity
Issue with NAT and multiple WAN interfaces
Hello,
I am having some difficulty implementing a simple NAT setup with
multiple WAN interfaces.
The setup consists of desktop PC's on a 10.1.100.0/16 network and
VoIP servers on a 10.1.20.0/16 network. These access the internet
through a Vyatta installation with a single LAN interface eth0
(10.1.30.1/16).
The Vyatta server is configured with one LAN interface and 4x ADSL
PPPOE interfaces (pppoe0-pppoe3). Currently all traffic is NAT'ed
through pppoe3, which is set up as Vyatta's default route.
What I need to do is:
1) Use Source NAT to selectively route outbound traffic from the
LAN through different WAN interfaces depending on the IP address
of the internal PC. This will allow me to send the (10.1.20.0/16) VoIP
traffic out a different WAN interface to general internet
(10.1.100.0/16) traffic.
2) Perform Destination NAT on incoming WAN packets based on
interface and destination port. This will allow me to send incoming
VoIP packets from any WAN interface to a VoIP server on the LAN.
At the moment I'm running into problems:
http://www.vyatta.org/node/4675
1/17
22/4/2014
1) When using Source NAT, any rule that does not use the current
default route/device seems to be ignored. For some reason Vyatta is
just skipping over the rule. I have no idea why this is happening, but
if I change the outbound interface and outgoing address to that of
default route (pppoe3), the rule works. For example, rule 5 in my
configuration never shows any hits in the statistics when pppoe3 is set
as the default route, all traffic hits rule 10 instead, which is using the
default route interface.
2) When using Destination NAT to redirect traffic from a WAN
interface which is not the default route, I end up with an
asynchronous routing scenario.
For example, rule 1070 in my configuration collects data from
external clients coming in on pppoe0, port 4569 (IAX2). It then sends
it to internal address 10.1.20.5 (VoIP Server) - This works correctly,
and data can be seen arriving at the server. However, when 10.1.20.5
replies, data can be seen leaving the VoIP server and arriving at
Vyatta. It is then for some reason sent out the default route interface
(pppoe3) instead of the originating WAN interface (pppoe0).
Any ideas why this is happening? Isn't Vyatta supposed to maintain
session state and send things back out the interface from which they
came? When I check the packets leaving pppoe3, they actually have
the correct source address of pppoe0, so its like the NAT side of
things is working, its just getting screwed up during routing.
Here is my sanitized current configuration:
interfaces{
etherneteth0{
address10.1.30.1/16
duplexauto
hwid00:0c:29:64:a1:43
smp_affinityauto
speedauto
}
etherneteth1{
duplexauto
hwid00:0c:29:64:a1:6b
pppoe0{
defaultroutenone
mtu1492
nameserverauto
passwordpassword
useridadsl_voip
}
smp_affinityauto
speedauto
}
etherneteth2{
duplexauto
hwid00:0c:29:64:a1:4d
pppoe1{
defaultroutenone
2/17
22/4/2014
mtu1492
nameserverauto
passwordpassword
useridadsl_inet2
}
smp_affinityauto
speedauto
}
etherneteth3{
duplexauto
hwid00:0c:29:64:a1:57
pppoe2{
defaultroutenone
mtu1492
nameserverauto
passwordpassword
useridadsl_vpn
}
smp_affinityauto
speedauto
}
etherneteth4{
duplexauto
hwid00:0c:29:64:a1:61
pppoe3{
defaultrouteauto
mtu1492
nameserverauto
passwordpassword
trafficpolicy{
outVoIPPriority
}
useridadsl_inet
}
smp_affinityauto
speedauto
}
loopbacklo{
}
}
protocols{
static{
interfaceroute58.1.1.1/32{
nexthopinterfacepppoe2{
}
}
}
}
}
}
}
}
}
}
service{
nat{
rule5{
description"NATforVoIPServers"
outboundinterfacepppoe0
3/17
22/4/2014
outsideaddress{
address58.3.3.3
}
source{
address10.1.0.0/16
}
typesource
}
rule10{
description"GeneralOutboundNAT"
outsideaddress{
address150.1.1.1
}
source{
address10.1.0.0/16
}
typesource
}
rule15{
description"NATforVoIPServers"
outsideaddress{
address58.3.3.3
}
source{
address10.1.20.0/24
}
typesource
}
rule1000{
description"IncommingIMAP"
destination{
address150.1.1.1
port143
}
inboundinterfacepppoe3
insideaddress{
address10.1.10.6
}
protocoltcp
source{
address0.0.0.0/0
}
typedestination
}
rule1010{
destination{
address202.1.1.1
port3000
}
insideaddress{
address10.1.11.5
port3389
}
protocoludp
typedestination
}
rule1020{
descriptionRulesforVoIP
destination{
port50605090
}
4/17
22/4/2014
insideaddress{
address10.1.20.1
}
protocoltcp
typedestination
}
rule1030{
destination{
port50605090
}
insideaddress{
address10.1.20.1
}
protocoludp
typedestination
}
rule1040{
destination{
port3000031000
}
insideaddress{
address10.1.20.1
}
protocoludp
typedestination
}
rule1050{
destination{
port2021
}
insideaddress{
address10.1.20.1
}
protocoltcp
typedestination
}
rule1060{
destination{
address150.1.1.1
port85
}
insideaddress{
address10.1.115.188
}
protocoltcp
source{
address0.0.0.0/0
}
typedestination
}
rule1070{
destination{
address58.3.3.3
port4569
}
insideaddress{
address10.1.20.5
}
protocoludp
source{
5/17
22/4/2014
address0.0.0.0/0
}
typedestination
}
}
ssh{
port22
protocolversion2
}
}
system{
hostnamevyatta.server.com
login{
banner{
prelogin"VyattaServer"
}
uservyatta{
authentication{
encryptedpasswordXXXXXXXXXXXXXXXXXXXXXX
plaintextpassword""
}
leveladmin
}
}
ntpserver0.vyatta.pool.ntp.org
package{
autosync1
repositorycommunity{
componentsmain
distributionstable
password""
urlhttp://packages.vyatta.com/vyatta(http://pack
ages.vyatta.com/vyatta)
username""
}
}
syslog{
global{
facilityall{
levelnotice
}
facilityprotocols{
leveldebug
}
}
}
timezoneAustralia/Sydney
}
trafficpolicy{
shaperVoIPPriority{
bandwidth650kbit
class10{
bandwidth60%
burst15k
ceiling100%
description"VoIPRTPtraffic"
matchVOIPRTP{
ip{
dscp46
}
}
queuetypefairqueue
}
class20{
bandwidth5%
6/17
22/4/2014
burst15k
ceiling100%
description"VoIPSIPTraffic"
matchVOIPSIP{
ip{
dscp26
}
}
queuetypefairqueue
}
default{
bandwidth15%
burst15k
ceiling100%
queuetypefairqueue
}
description"QoSpolicytodecreaseVoIPlatency"
}
}
vpn{
ipsec{
espgroupp2{
compressiondisable
lifetime1800
modetunnel
pfsenable
proposal1{
encryptionaes128
hashsha1
}
}
ikegroupp1{
lifetime7200
proposal1{
dhgroup2
encryptionaes128
hashsha1
}
}
ipsecinterfaces{
interfacepppoe2
}
logging{
logmodesall
}
sitetosite{
peer58.1.1.1{
authentication{
modepresharedsecret
presharedsecretREALPSKGOESHERE
}
ikegroupp1
localip202.1.1.1
tunnel1{
allownatnetworksdisable
allowpublicnetworksdisable
espgroupp2
localsubnet10.1.0.0/16
remotesubnet10.4.0.0/16
}
}
peer58.2.2.2{
authentication{
modepresharedsecret
7/17
22/4/2014
}
ikegroupp1
localip202.1.1.1
tunnel1{
espgroupp2
}
}
peer124.1.1.1{
authentication{
modepresharedsecret
}
ikegroupp1
localip202.1.1.1
tunnel1{
espgroupp2
}
}
peer202.2.2.2{
authentication{
modersa
rsakeynameWollongongkey
}
ikegroupp1
localip202.1.1.1
tunnel1{
espgroupp2
}
}
}
}
rsakeys{
rsakeynameWollongongkey{
rsakeyREALRSAKEYGOESHERE
}
}
}
/*Warning:Donotremovethefollowingline.*/
/*===vyattaconfigversion:"cluster@1:conntracksync@1:dhcpre
lay@1:dhcpserver@4:firewall@3:ipsec@2:nat@3:qos@1:quagga@2:syste
m@3:vrrp@1:wanloadbalance@2:webgui@1:webproxy@1"===*/
Result of "show interfaces":

vyatta@io:~$showinterfaces
InterfaceIPAddressStateLinkDescription
eth010.1.30.1/16upup
eth1upup
eth2upup
eth3upup
8/17
22/4/2014
eth4upup
lo127.0.0.1/8upup
lo::1/128upup
pppoe058.3.3.3upup
pppoe1202.3.3.3upup
pppoe2202.1.1.1upup
pppoe3150.1.1.1upup
vyatta@io:~$
IP Tables Info:
IPTABLES
FilterChainDetails
ChainINPUT(policyACCEPT0packets,0bytes)
pktsbytestargetprotoptinoutsource
destination
951K337MVYATTA_POST_FW_HOOKall**0.0.0.0/
00.0.0.0/0
ChainFORWARD(policyACCEPT0packets,0bytes)
destination
300K133MVYATTA_POST_FW_HOOKall**0.0.0.0/
00.0.0.0/0
ChainOUTPUT(policyACCEPT22952packets,6031Kbytes)
destination
ChainVYATTA_POST_FW_HOOK(2references)
destination
1251K471MACCEPTall**0.0.0.0/0
0.0.0.0/0
NatChainDetails
ChainPREROUTING(policyACCEPT12901packets,926Kbytes)
destination
13084936KVYATTA_PRE_DNAT_HOOKall**0.0.0.0
/00.0.0.0/0
1789030DNATtcppppoe3*0.0.0.0/0
150.1.1.1tcpdpt:143/*NAT1000*/to:10.1.10.6
00DNATudppppoe2*0.0.0.0/0
202.1.1.1udpdpt:3000/*NAT1010*/to:10.1.11.5:3389
0.0.0.0/0multiportdports5060:5090/*NAT1020*/
to:10.1.20.1
0.0.0.0/0multiportdports5060:5090/*NAT1030*/
to:10.1.20.1
0.0.0.0/0multiportdports30000:31000/*NAT1040*
/to:10.1.20.1
0.0.0.0/0multiportdports20:21/*NAT1050*/to:1
0.1.20.1
9/17
22/4/2014
150.1.1.1tcpdpt:85/*NAT1060*/to:10.1.115.188
58.3.3.3udpdpt:4569/*NAT1070*/to:10.1.20.5
ChainPOSTROUTING(policyACCEPT7741packets,565Kbytes)
destination
145911002KVYATTA_PRE_SNAT_HOOKall**0.0.0.0
/00.0.0.0/0
00SNATall*pppoe010.1.0.0/16
0.0.0.0/0/*NAT5*/to:58.3.3.3
6850436KSNATall*pppoe310.1.0.0/16
0.0.0.0/0/*NAT10*/to:150.1.1.1
00SNATall*pppoe010.1.20.0/24
0.0.0.0/0/*NAT15*/to:58.3.3.3
destination
ChainVYATTA_PRE_DNAT_HOOK(1references)
destination
13084936KRETURNall**0.0.0.0/0
0.0.0.0/0
ChainVYATTA_PRE_SNAT_HOOK(1references)
destination
145911002KRETURNall**0.0.0.0/0
0.0.0.0/0
MangleChainDetails
ChainPREROUTING(policyACCEPT95443packets,30Mbytes)
destination
ChainINPUT(policyACCEPT80297packets,28Mbytes)
destination
ChainFORWARD(policyACCEPT15144packets,1994Kbytes)
destination
destination
ChainPOSTROUTING(policyACCEPT18608packets,3133Kbytes)
destination
RawChainDetails
ChainPREROUTING(policyACCEPT0packets,0bytes)
destination
1260K474MVYATTA_PRE_CT_PREROUTING_HOOKall**
0.0.0.0/00.0.0.0/0
1260K474MNAT_CONNTRACKall**0.0.0.0/0
10/17
22/4/2014
0.0.0.0/0
00NOTRACKall**0.0.0.0/0
0.0.0.0/0
ChainOUTPUT(policyACCEPT0packets,0bytes)
destination
232036124KVYATTA_PRE_CT_OUTPUT_HOOKall**0.
0.0.0/00.0.0.0/0
232036124KNAT_CONNTRACKall**0.0.0.0/0
0.0.0.0/0
00NOTRACKall**0.0.0.0/0
0.0.0.0/0
ChainNAT_CONNTRACK(2references)
destination
1284K480MACCEPTall**0.0.0.0/0
0.0.0.0/0
ChainVYATTA_PRE_CT_OUTPUT_HOOK(1references)
destination
232036124KRETURNall**0.0.0.0/0
0.0.0.0/0
ChainVYATTA_PRE_CT_PREROUTING_HOOK(1references)
destination
1260K474MRETURNall**0.0.0.0/0
0.0.0.0/0
If anyone can offer suggestions as to what I'm doing wrong and how
to go about fixing these issues, it would be greatly appreciated.
Thanks,
Jeff
Top
or to post comments
Tue, 12/21/2010 09:00
Permalink
Singularity
As per another post I found on this forum, I have changed my config
to use load balancing rules with a single interface per rule to replace
my source NAT rules... This appears to be working... However I'm
still having issues with destination NAT.
Does anyone have any ideas about why I'd be having an asymmetric
routing issue when using multiple WAN interfaces with DNAT? Using
rule 1070 from my config (see previous post) as an example, I can
see packets come in pppoe0 from a remote address on port 4569.
11/17
22/4/2014
These are correctly NAT'ed to 10.1.20.5 which sees the request from
the remote address and sends a response back through the Vyatta
router. Vyatta then receives this request and correctly changes the
source address of the packet to that of pppoe0. It is at this point
where we run into problems - Vyatta now takes the packet and sends
it out any one of the WAN interfaces pppoe0, pppoe1, pppoe2 or
pppoe3, the interface picked seems to be random. How can I FORCE
Vyatta to choose the correct interface pppoe0?
Surely I can't be the only one having this sort of problem...? I've
gotta be going wrong somewhere configuration wise, yet as far as I
can see what I've done looks correct... Is there some sort of known
Vyatta limitation at work here? Does anyone have a successful
multiple WAN setup with destination NAT config they could share?
Thanks,
Jeff
Top
or to post comments
Tue, 12/21/2010 09:17
Permalink
Tijz
Hi Jeff,
No you're not the only one with this problem..
I'm having the same kind of problem, sadly though, no resolution as I
was just coming here to post it myself.
Instead of ppoe interfaces I just use two ethernet interfaces connected
to two different ADSL routers. I'm also having trouble using DNAT.
As you describe, only outside traffic targeting the "main" WAN
interface is working correctly, traffic targeting the other interface get's
natted ok but any return traffic is routed over the "main" WAN
interface...
I also fiddled with load balancing, but as far as I can see it forces you
to use masquerade nat, in which case any SNAT rule does not work
(As I understand it masquerade translated ANY AND ALL traffic with
the IP of the interface it is masquerading on).
So.. you're not alone in this, hopefully someone else can point us in a
right direction...
12/17
22/4/2014
Tijs
Top
or to post comments
Permalink
Tue, 12/21/2010 15:22
bjbrock
Not the answer but the reason...
Routing decisions are made prior to SNAT while DNAT operates on
the packets before routing. While this isn't the answer to your
question it is the logic behind what is happening. ie. You cannot use
NAT rules to route.
Top
or to post comments
Permalink
Tue, 12/21/2010 23:05
kherona
Hi Friend,
According to Vyatta NAT documentation, the type of NAT should be
masquerade in order to gain the benefit of using multiple interfaces.
in Vyatta you have 3 types of NAT:
source (based on source IP of incoming packets).
destination (based on destination IP of incoming packets).
masquerade (based on the interface the packets going to leave). (you
need to make source-based-routing in order for this to work).
Top
or to post comments
Wed, 12/22/2010 04:32
Permalink
Tijz
Hi all,
thanks for the replies
13/17
22/4/2014
But none of these post explain if it should be possible. In theory it

should though. Because in my case I want to replace our Draytek
Vigor 3300 hardware appliance with a vyatta virtual appliance. The
Draytek has no issues with SNAT using both interfaces.
Surely, if Draytek can do it, vyatta can. I hope....
Top
or to post comments
Wed, 12/22/2010 09:05
Permalink
Singularity
Ok, so after going over Vyatta and Netfilter / iproute2 documentation,
it has become apparent that this is actually a problem that requires
source based routing, something that Vyatta does not yet support
through the CLI.
That means that to get this to work, you will need to get your hands
dirty and edit the routing table directly to add in the required source
based rules.
For example, to get around the problems I was having the following
needs to be set up for rule 1070:
This sets up four separate routing tables, one per interface. Each table
has its interface as the default route sudoiprouteadddefaultdevpppoe0table1
sudoiprouteadddefaultdevpppoe1table2
Once this is done, we need to setup routing rules to send traffic to the
correct routing table. The following will send packets coming from
internal device 10.1.20.5 out through table 1, which has pppoe0 as its
default route device. Please note that for this to work, any DNAT /
SNAT rules in use MUST use the specified interface (in this case
pppoe0).
sudo ip rule add from 10.1.20.5 table 1
Unfortunately since this hasn't been done through the Vyatta CLI, the
changes aren't persistent and will disappear on reboot. To fix this, you
need to add anything you do you the file /etc/rc.d/rc.local - Here's an
14/17
22/4/2014
example of the one I am testing with atm...

echo"Settingupcustomroutingtables..."
#Setuptables
/sbin/iprouteadddefaultdevpppoe0table1
#LocalLANInternettraffictogooutpppoe3
/sbin/ipruleaddfrom10.1.100.0/24table4
#Emailandothergeneralservertraffictogooutpppoe3
#AllVoIPServertraffictogooutpppoe0
YMMV, but hopefully that helps you out a bit Tijz, has been driving
me crazy for about a week now . . .
Can any Vyatta employee's shed some light as to when sourced based
routing will be available through the CLI? Being the one of the most
requested features, It would sure make a lot of peoples lives easier.
Can we expect it in the next release?
Thanks,
Jeff
Top
or to post comments
Permalink
Fri, 12/24/2010 04:03
Tijz
Hi Jeff,
thanks for sharing your research on this!
Will try it, allthough it makes the configuration not very portable
which might become a problem...
Tijs
Top
or to post comments
15/17
22/4/2014
Permalink
Sat, 12/25/2010 05:48
Tijz
So, I just set this up. Yes I know, it's christmas.. i had a few hours to
kill before going to diner :)
I immediately ran into trouble, as this source based routing does not
solve my problem entirely.
In the good old draytek I DNAT-ed port 25 from both WAN interface
to my Exchange server. So that in case one of the WAN connections
broke down, mail could be delivered through the other WAN
connection.
Using source based routing however (the way I understand it at the
moment) I route EVERY traffic from one particular source, say my
Exchange server, through a specific interface (probably different then
the default gateway).
So I am still not able to DNAT prt 25 from both WAN connections to
one internal IP. Or am I missing something?
Top
or to post comments
Sat, 12/25/2010 21:43
Permalink
Singularity
Hi Tijz,
That situation makes things a little more difficult, but its still possible.
What you need to do instead is set up iptables to MARK packets
when they enter the router based on address / interface, then route
based on packet marking instead. I've done this with a CentOS install
before and once set up it does work well.
An example is explained pretty well in this blog post:
http://nerdboys.com/2006/05/05/conning-the-mark-multiwanconnections-using-iptables-mark-connmark-and-iproute2/
(http://nerdboys.com/2006/05/05/conning-the-mark-multiwan-connectionsusing-iptables-mark-connmark-and-iproute2/)
Some other sites you might find useful:

http://lartc.org/howto/lartc.netfilter.html
16/17
22/4/2014
(http://lartc.org/howto/lartc.netfilter.html)
http://www.linuxtopia.org/Linux_Firewall_iptables/x4368.html
(http://www.linuxtopia.org/Linux_Firewall_iptables/x4368.html)
Top
or to post comments
Permalink
Mon, 12/27/2010 00:51
Tijz
Ok, thanks! will look into that
Top
or to post comments
Vyatta.com (http://www.vyatta.com) | Support Center (http://www2.vyatta.com/support) | Vyatta

University (http://www.vyatta.com/support/training) | Contact Us
(http://www.vyatta.com/company/contact)
2012 Vyatta Inc. - All rights reserved.

Vyatta and the Vyatta logo are registered trademarks of Vyatta, Inc. Other marks are trademarks
of their respective holders.
17/17

Issue With NAT and Multiple WAN Interfaces - Vyatta

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Issue With NAT and Multiple WAN Interfaces - Vyatta

Caricato da

Copyright:

Formati disponibili

22/4/2014

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

SUPPORT & SERVICES

Log in or register to post comments

Fri, 12/17/2010 06:52

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Result of "show interfaces":

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Tue, 12/21/2010 09:00

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Tue, 12/21/2010 09:17

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Tue, 12/21/2010 15:22

Tue, 12/21/2010 23:05

Wed, 12/22/2010 04:32

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

But none of these post explain if it should be possible. In theory it

Wed, 12/22/2010 09:05

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

example of the one I am testing with atm...

Fri, 12/24/2010 04:03

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Sat, 12/25/2010 05:48

Sat, 12/25/2010 21:43

Some other sites you might find useful:

Issue with NAT and multiple WAN interfaces | Vyatta.org Community

Mon, 12/27/2010 00:51

Vyatta.com (http://www.vyatta.com) | Support Center (http://www2.vyatta.com/support) | Vyatta

2012 Vyatta Inc. - All rights reserved.

Potrebbero piacerti anche