From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel Beckham" Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't check out Date: Tue, 4 Mar 2003 14:49:20 -0600 Sender: netfilter-admin@lists.netfilter.org Message-ID: <002101c2e28f$899e7860$0a02010a@danbeck> References: <015401c2e273$31980d00$0a02010a@danbeck> <3E64E9A4.6010008@sqlcomp.com> <003601c2e27f$c7cf49d0$0a02010a@danbeck> <3E64FD61.50107@sqlcomp.com> Reply-To: "Daniel Beckham" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C2E25D.3D62DB80" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: Netfilter This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C2E25D.3D62DB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Arrrgh, I take it you don't have any help for me then. =3D) Daniel ----- Original Message -----=20 From: Steve Reynolds=20 To: Daniel Beckham=20 Sent: Tuesday, March 04, 2003 1:24 PM Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't check out I saw framing problems similar to what you were seeing last year. = really weird. thanks steve Daniel Beckham wrote: No.. just 10base-T 10 and 100. Daniel ----- Original Message -----=20 From: Steve Reynolds=20 To: Daniel Beckham=20 Sent: Tuesday, March 04, 2003 12:00 PM Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't check out dumb question. is there any token ring in your network at all. thanks steve Daniel Beckham wrote: Yeah, I actually DNAT and SNAT private addresses to public addresses on = the public interface on the firewall for some of the developers here, so I = know that using that SNAT line *should* work, as it does in practice already. To answer your questions, here is the interface setup on the firewall. eth0 -- public interface (207.111.175.64/26) to the external router (internet) and normal traffic from and to the 129.41.69.128/26 subnet = comes over this wire eth1 -- private interface to local network using 10.1.2.0/24 address = space tun0 -- a openvpn tunnel between the remote 10.1.1.0/24 network and = private 10.1.2.0/24 network The remote network is a private address space behind a router in the = public 129.41.69.128/26 address space. The eth0 interface does not = specifically listen for traffic from 129.41.69.137, instead it's just the gateway for = any external public traffic incoming to the 207.111.175.64/26 subnet. There = are also several eth0:N aliases for local private machines that are = DNAT/SNAT'ed to public addresses for different reasons. I use the following lines to allow all traffic to be forwarded from the private interface (eth1) and the openvpn tunnel (tun0): $IPTABLES -A FORWARD -i tun+ -j ACCEPT $IPTABLES -A FORWARD -i tap+ -j ACCEPT $IPTABLES -A FORWARD -i eth1 -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT The line for the tap device isn't really necessary for my setup, but it = is just there in case I decide to fool with bridging. As far as I can tell, things should be working correctly. And the funny thing is that they do, sort of. Responses to the DNAT'ed traffic = initiated by the client returns over the tunnel, but only part of the response = traffic by the client goes back out. I.e. I can send very tiny emails, but = nothing large like a reply. I can download files via ftp, but can not upload. = And I've confirmed that traffic outgoing from the client is going over the tunnel. This is driving me crazy. =3D) Daniel Beckham dealnews.com ----- Original Message ----- From: To: "Daniel Beckham" Sent: Tuesday, March 04, 2003 10:32 AM Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't check out =20 Hi Daniel. The second rule you mention below would be correct and needed for these connections to work properly, so keep it in there ..... a couple of = things I thought about, though ..... .did you setup an alias on the firewall =20 box's =20 'external' network card to listen for packets destined for 129.41.69.137 = ? ..... as follows : ifconfig ethWHATEVER:0 129.41.69.137 netmask your.mask.goes.here ... also, what does your filter table look like, is the FORWARD chain =20 setup =20 correctly to allow the connection through the firewall ? Regards, Richard. Richard Oatridge Head of IT, Start-global Ltd http://www.start-global.com tel : +44 1564 779297 email : richardo@start-global.com |--------+-----------------------------------> | | "Daniel Beckham" | | | | | | Sent by: | | | netfilter-admin@lists.net| | | filter.org | | | | | | | | | 04/03/2003 15:29 | | | | |--------+-----------------------------------> -------------------------------------------------------------------------= -- =20 ----------------------------------------------| =20 | =20 | =20 | To: "Netfilter" =20 | =20 | cc: =20 | =20 | Subject: Re: DNAT and VPN Tunnel problems, traffic checks =20 in, but doesn't check out | =20 -------------------------------------------------------------------------= -- =20 ----------------------------------------------| =20 Thank you for your help, but I don't really understand what you are = trying to tell me. The first config line makes sense and that is similar to = what I'm doing now. Although, I'm not using any specific ports because I'm testing at the moment. The second line is confusing though. Why would I SNAT a 10.1.1.0/24 address to another 10.1.1.0/24 address? I was thinking you may have meant a 10.1.2.0/24 address, but that makes even less sense as that is the = client trying to connect in the first place. Also, why would you use a = 10.1.1.7 as the -d option, the destination address? Btw, I tried several = combinations including your example just for the hell of it, but none of them work. = =3D) Something that I did not mention before though is that I have tried = this: iptables -t nat -A POSTROUTING -s 10.1.1.7 -p tcp -j SNAT --to 129.41.69.137 I would think this would solve the problem, but this doesn't help. = Anyone else have any ideas? Thank you for your help, Daniel Beckham dealnews.com ----- Original Message ----- From: "Pavan Gokarn" To: "Daniel Beckham" Sent: Tuesday, March 04, 2003 12:15 AM Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but = doesn't check out =20 yes daniel you'll need a rule to get the packets back from the remote network back into your network. these will be the rules substitute them eoth you desired ip addresses for outgoing connection # iptables -t nat -A PREROUTING -d 129.41.69.137 -p tcp --dport 25 -j DNAT --to 10.1.1.7 for incomming replies # iptables -t nat -A POSTROUTING -d 10.1.1.7 -p tcp --dport 25 -j =20 SNAT --to =20 10.1.1.something remember not to allow all types of connections to in and out because =20 this =20 might cause a security threat. substitute the 10.1.1.something ip =20 address =20 with the ip that connects/talks to the 10.1.1.7 address. this might work hope this was helpful regards ----- Original Message ----- From: Daniel Beckham To: Sent: Tuesday, March 04, 2003 3:53 AM Subject: DNAT and VPN Tunnel problems, traffic checks in, but doesn't =20 check =20 out =20 I'm seeing a strange issue with DNAT'ed traffic over a VPN. Incoming packets arrive just fine, but outgoing traffic has trouble for large =20 streams =20 of tcp data. My setup is fairly simple. A group of machines on a private network =20 behind =20 a gateway/firewall (netfilter) connect through an OpenVPN tunnel to a =20 remote =20 group of machines on a different private network. Local subnet: 10.1.2.0/24 Remote Subnet 10.1.1.0/24 Client machines on the local subnet can freely talk to servers on the =20 remote =20 subnet through the vpn with out any problems. Until the vpn tunnel was functional, client machines on the local =20 private =20 network connected to mail.dealnews.com to retrieve and send mail, a =20 public =20 interface of the mail server on the remote private network. Now that =20 the =20 vpn is working, they need to retrieve and send mail using the private address 10.1.1.7. For several reasons, one being laptop administration, I don't want to =20 change =20 all of the mail client's ip addresses to 10.1.1.7. I want to use =20 iptables =20 to DNAT packets headed for the public mail address (mail.dealnews.com) =20 to =20 the private mail address 10.1.1.7 so that packets are routed over the =20 vpn =20 instead of the internet. This is how I attempted to configure iptables: iptables -t nat -A PREROUTING -s 10.1.2.10 -d 129.41.69.137 -p all -j DNAT --to-destination 10.1.1.7 The -s option is there so that I can test the config myself without =20 Borking =20 the rest of the network. This seems to work at first as I can see traffic sent from the client =20 to =20 mail.dealnews.com over the tunnel interface on the remote network. =20 What =20 happens though, is although that I can connect to the remote mail =20 server =20 just fine through IMAP and even send out a very small email message =20 through =20 SMTP, large mail messages just stall and fail. Ftp is the same way. =20 I =20 can =20 transfer files from the remote server, but I can not send any sizeable =20 file =20 to the server. I know for sure that traffic is traveling over the vpn tunnel because I'm dumping the tunnel interface up at the remote =20 network. =20 This sounds like something to do with fragmentation or possibly =20 something =20 along that line of thinking, but I can not for the life of me figure =20 out =20 what this is. I wondered if possibly, I needed another rule to DNAT packets coming =20 from =20 the remote network over the tunnel back to the public =20 mail.dealnews.com =20 ip =20 address: iptables -t nat -A PREROUTING -s 129.41.69.37 -d 10.1.2.10 -p all -j DNAT --to-destination 129.41.69.137 But this didn't seem to help anything. Could anyone help me figure out how I can work around this? Again, =20 incoming =20 traffic through the tunnel seems to work just fine, but outgoing =20 traffic =20 only half seems to work. As strange as that sounds. Thanks, Daniel dealnews.com =20 =20 =20 =20 ------=_NextPart_000_001E_01C2E25D.3D62DB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Arrrgh, I take it you don't have any = help for me=20 then. =3D)

Daniel
 
----- Original Message -----
From:=20 Steve = Reynolds=20
To: Daniel Beckham =
Sent: Tuesday, March 04, 2003 = 1:24=20 PM
Subject: Re: DNAT and VPN = Tunnel=20 problems, traffic checks in, but doesn't check out

I saw framing problems similar to what you were seeing = last=20 year.  really weird.
thanks
steve

Daniel Beckham = wrote:
No.. just 10base-T 10 and = 100.
 
Daniel
-----=20 Original Message ----- From:=20 Steve = Reynolds=20 To:=20 Daniel Beckham = Sent:=20 Tuesday, March 04, 2003 12:00 PM Subject:=20 Re: DNAT and VPN Tunnel problems, traffic checks in, but doesn't = check=20 out

dumb question. is there any token ring in your = network at=20 all.
thanks
steve

Daniel Beckham wrote:
Yeah, I actually DNAT and SNAT private =
addresses to public addresses on the
public interface on the firewall for some of the developers here, so I =
know
that using that SNAT line *should* work, as it does in practice already.

To answer your questions, here is the interface setup on the firewall.

eth0 -- public interface (207.111.175.64/26) to the external router
(internet) and normal traffic from and to the 129.41.69.128/26 subnet =
comes
over this wire
eth1 -- private interface to local network using 10.1.2.0/24 address =
space
tun0 -- a openvpn tunnel between the remote 10.1.1.0/24 network and =
private
10.1.2.0/24 network

The remote network is a private address space behind a router in the =
public
129.41.69.128/26 address space.  The eth0 interface does not =
specifically
listen for traffic from 129.41.69.137, instead it's just the gateway for =
any
external public traffic incoming to the 207.111.175.64/26 subnet.  There =
are
also several eth0:N aliases for local private machines that are =
DNAT/SNAT'ed
to public addresses for different reasons.

I use the following lines to allow all traffic to be forwarded from the
private interface (eth1) and the openvpn tunnel (tun0):
$IPTABLES -A FORWARD -i tun+ -j ACCEPT
$IPTABLES -A FORWARD -i tap+ -j ACCEPT
$IPTABLES -A FORWARD -i eth1 -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

The line for the tap device isn't really necessary for my setup, but it =
is
just there in case I decide to fool with bridging.

As far as I can tell, things should be working correctly.  And the funny
thing is that they do, sort of.  Responses to the DNAT'ed traffic =
initiated
by the client returns over the tunnel, but only part of the response =
traffic
by the client goes back out.  I.e. I can send very tiny emails, but =
nothing
large like a reply.  I can download files via ftp, but can not upload.   =
And
I've confirmed that traffic outgoing from the client is going over the
tunnel.

This is driving me crazy. =3D)

Daniel Beckham
dealnews.com


----- Original Message -----
From: <richardo@start-global.com&g=
t;
To: "Daniel Beckham" <danbeck-netfilter@deal=
news.com>
Sent: Tuesday, March 04, 2003 10:32 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but =
doesn't
check out


  
Hi Daniel.

The second rule you mention below would be correct and needed for these
connections to work properly, so keep it in there ..... a couple of =
things
I thought about, though ..... .did you setup an alias on the firewall
    
box's
  
'external' network card =
to listen for packets destined for 129.41.69.137 ?
..... as follows :

ifconfig ethWHATEVER:0 129.41.69.137 netmask your.mask.goes.here

... also, what does your filter table look like, is the FORWARD chain
    
setup
  
correctly to allow the =
connection through the firewall ?

Regards,
Richard.

Richard Oatridge
Head of IT, Start-global Ltd
http://www.start-global.com
tel :  +44 1564 779297
email : richardo@start-global.com


|--------+----------------------------------->
|        |          "Daniel Beckham"         |
|        |          <danbeck-netfi=
lter@dealne|
|        |          ws.com>                  |
|        |          Sent by:                 |
|        |          netfilter-admin@lists.net|
|        |          filter.org               |
|        |                                   |
|        |                                   |
|        |          04/03/2003 15:29         |
|        |                                   |
|--------+----------------------------------->

-------------------------------------------------------------------------=
--
    
----------------------------------------------|
  
  |
    
|
  
  |       To:     =
"Netfilter" <netfilter@lists.netfilt=
er.org>
    
|
  
  |       cc:
    
|
  
  |       Subject:     =
Re: DNAT and VPN Tunnel problems, traffic checks
    
in, but doesn't check out   =
                        |
  
---------------------------------------------------------------=
------------
    
----------------------------------------------|
  
Thank you for your =
help, but I don't really understand what you are trying
to tell me.  The first config line makes sense and that is similar to =
what
I'm doing now.  Although, I'm not using any specific ports because I'm
testing at the moment.

The second line is confusing though.  Why would I SNAT a 10.1.1.0/24
address
to another 10.1.1.0/24 address?  I was thinking you may have meant a
10.1.2.0/24 address, but that makes even less sense as that is the =
client
trying to connect in the first place.  Also, why would you use a =
10.1.1.7
as
the -d option, the destination address?  Btw, I tried several =
combinations
including your example just for the hell of it, but none of them work. =
=3D)

Something that I did not mention before though is that I have tried =
this:
iptables -t nat -A POSTROUTING -s 10.1.1.7 -p tcp -j SNAT --to
129.41.69.137

I would think this would solve the problem, but this doesn't help.  =
Anyone
else have any ideas?

Thank you for your help,

Daniel Beckham
dealnews.com



----- Original Message -----
From: "Pavan Gokarn" <pavang@techknowledge.ws>
To: "Daniel Beckham" <danbeck-netfilter@deal=
news.com>
Sent: Tuesday, March 04, 2003 12:15 AM
Subject: Re: DNAT and VPN Tunnel problems, traffic checks in, but =
doesn't
check out


    
yes daniel you'll =
need a rule to get the packets back from the remote
network back into your network.
these will be the rules substitute them eoth you desired ip addresses
for outgoing connection
# iptables -t nat -A PREROUTING -d 129.41.69.137 -p tcp --dport 25 -j
DNAT --to 10.1.1.7
for incomming replies
# iptables -t nat -A POSTROUTING -d 10.1.1.7 -p tcp --dport 25 -j
      
SNAT --to
    
10.1.1.something

remember not to allow all types of connections to in and out because
      
this
  
might cause a =
security threat. substitute the 10.1.1.something ip
      
address
  
with the ip that =
connects/talks to the 10.1.1.7 address.
this might work
hope this was helpful
regards

----- Original Message -----
From: Daniel Beckham <danbeck-netfilter@deal=
news.com>
To: <netfilter@lists.netfilt=
er.org>
Sent: Tuesday, March 04, 2003 3:53 AM
Subject: DNAT and VPN Tunnel problems, traffic checks in, but doesn't
      
check
    
out


      
I'm seeing a =
strange issue with DNAT'ed traffic over a VPN.  Incoming
packets arrive just fine, but outgoing traffic has trouble for large
        
streams
      
of tcp data.

My setup is fairly simple.   A group of machines on a private network
        
behind
      
a gateway/firewall =
(netfilter) connect through an OpenVPN tunnel to a
        
remote
      
group of machines =
on a different private network.

Local subnet: 10.1.2.0/24
Remote Subnet 10.1.1.0/24

Client machines on the local subnet can freely talk to servers on the
        
remote
      
subnet through the =
vpn with out any problems.

Until the vpn tunnel was functional, client machines on the local
        
private
    
network connected =
to mail.dealnews.com to retrieve and send mail, a
        
public
    
interface of the =
mail server on the remote private network.  Now that
        
the
    
vpn is working, =
they need to retrieve and send mail using the private
address 10.1.1.7.

For several reasons, one being laptop administration, I don't want to
        
change
      
all of the mail =
client's ip addresses to 10.1.1.7.  I want to use
        
iptables
    
to DNAT packets =
headed for the public mail address (mail.dealnews.com)
        
to
    
the private mail =
address 10.1.1.7 so that packets are routed over the
        
vpn
    
instead of the =
internet.

This is how I attempted to configure iptables:
iptables -t nat -A PREROUTING -s 10.1.2.10 -d 129.41.69.137 -p all -j
DNAT --to-destination 10.1.1.7

The -s option is there so that I can test the config myself without
        
Borking
      
the rest of the =
network.

This seems to work at first as I can see traffic sent from the client
        
to
    
mail.dealnews.com =
over the tunnel interface on the remote network.
        
What
    
happens though, is =
although that I can connect to the remote mail
        
server

    
just fine through =
IMAP and even send out a very small email message
        
through
      
SMTP, large mail =
messages just stall and fail.  Ftp is the same way.
        
I
  
can
      
transfer files from =
the remote server, but I can not send any sizeable
        
file
      
to the server.  I =
know for sure that traffic is traveling over the vpn
tunnel because I'm dumping the tunnel interface up at the remote
        
network.
    
This sounds like =
something to do with fragmentation or possibly
        
something
    
along that line of =
thinking, but I can not for the life of me figure
        
out
    
what this is.

I wondered if possibly, I needed another rule to DNAT packets coming
        
from
    
the remote network =
over the tunnel back to the public
        
mail.dealnews.com
  
ip
    
address:
iptables -t nat -A PREROUTING -s 129.41.69.37 -d 10.1.2.10 -p all -j
DNAT --to-destination 129.41.69.137

But this didn't seem to help anything.

Could anyone help me figure out how I can work around this?  Again,
        
incoming
      
traffic through the =
tunnel seems to work just fine, but outgoing
        
traffic
    
only half seems to =
work.  As strange as that sounds.

Thanks,

Daniel
dealnews.com




        
      




    







  =


= ------=_NextPart_000_001E_01C2E25D.3D62DB80--