Linux Netfilter discussions
 help / color / mirror / Atom feed
* (unknown)
@ 2007-09-15 23:15 "Mario Hülsegge"
  2007-09-16 11:05 ` Port-based routing with OpenVPN Pascal Hambourg
  0 siblings, 1 reply; 7+ messages in thread
From: "Mario Hülsegge" @ 2007-09-15 23:15 UTC (permalink / raw)
  To: netfilter

hi,

i am trying to set up routing of all outgoing http-requests on my 
workstation through my openvpn gateway (tun0). the web told me to do it:

iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 4
ip rule add fwmark 4 lookup 3
ip route add default dev tun0 table 3


the problem is that it does not work. tcpdump gives me:

00:28:00.461045 IP (tos 0x0, ttl  64, id 28447, offset 0, flags [DF], 
proto: UDP (17), length: 71) 192.168.0.125.1049 > vroot.domain: [udp sum 
ok]  62654+ PTR? 67.11.71.195.in-addr.arpa. (43)
00:28:00.515190 IP (tos 0x0, ttl  56, id 0, offset 0, flags [DF], proto: 
UDP (17), length: 127) vroot.domain > 192.168.0.125.1049:  62654 NXDomain 
q: PTR? 67.11.71.195.in-addr.arpa. 0/1/0 ns: 71.195.in-addr.arpa. (99)
00:28:01.459744 arp who-has 195.71.11.67 tell 192.168.0.125
00:28:02.459844 arp who-has 195.71.11.67 tell 192.168.0.125


the arp-requests dont seem to be right, any suggestions?

Mario
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-15 23:15 (unknown) "Mario Hülsegge"
@ 2007-09-16 11:05 ` Pascal Hambourg
  2007-09-19 21:38   ` Mario Hülsegge
  2007-09-25 22:14   ` Mario Hülsegge
  0 siblings, 2 replies; 7+ messages in thread
From: Pascal Hambourg @ 2007-09-16 11:05 UTC (permalink / raw)
  To: netfilter

Hello,

Mario Hülsegge a écrit :
> 
> i am trying to set up routing of all outgoing http-requests on my 
> workstation through my openvpn gateway (tun0). the web told me to do it:
> 
> iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 4
> ip rule add fwmark 4 lookup 3
> ip route add default dev tun0 table 3

Looks fine.

> the problem is that it does not work. tcpdump gives me:
> 
> 00:28:00.461045 IP (tos 0x0, ttl  64, id 28447, offset 0, flags [DF], 
> proto: UDP (17), length: 71) 192.168.0.125.1049 > vroot.domain: [udp sum 
> ok]  62654+ PTR? 67.11.71.195.in-addr.arpa. (43)
> 00:28:00.515190 IP (tos 0x0, ttl  56, id 0, offset 0, flags [DF], proto: 
> UDP (17), length: 127) vroot.domain > 192.168.0.125.1049:  62654 NXDomain 
> q: PTR? 67.11.71.195.in-addr.arpa. 0/1/0 ns: 71.195.in-addr.arpa. (99)
> 00:28:01.459744 arp who-has 195.71.11.67 tell 192.168.0.125
> 00:28:02.459844 arp who-has 195.71.11.67 tell 192.168.0.125

Was this trace captured on interface tun0 ?
Please use option -n so addresses and port numbers are not converted 
into confusing names.
What is the address of vroot ? Is it the other end of the VPN ?
Is the OpenVPN link configured in TUN (IP) or TAP (ethernet) mode ? The 
interface name tun0 suggests TUN mode, but the ARP requests suggest TAP 
mode. If it is TAP mode, you must specify the gateway address in the ip 
route statement just as you would do with a gateway on an ethernet link.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-16 11:05 ` Port-based routing with OpenVPN Pascal Hambourg
@ 2007-09-19 21:38   ` Mario Hülsegge
  2007-09-25 22:14   ` Mario Hülsegge
  1 sibling, 0 replies; 7+ messages in thread
From: Mario Hülsegge @ 2007-09-19 21:38 UTC (permalink / raw)
  To: netfilter

Hi,

and thank you for answering despite the fact i forgot to set a
subject :)

> Was this trace captured on interface tun0 ?
yes

> What is the address of vroot ? Is it the other end of the VPN ?
no, it is just my dns-server that has nothing to do with the vpn.

> Is the OpenVPN link configured in TUN (IP) or TAP (ethernet) mode ?
it is in tun mode, i have no idea why it acts like in tap mode.

Mario



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-16 11:05 ` Port-based routing with OpenVPN Pascal Hambourg
  2007-09-19 21:38   ` Mario Hülsegge
@ 2007-09-25 22:14   ` Mario Hülsegge
  2007-09-26 10:33     ` Pascal Hambourg
  1 sibling, 1 reply; 7+ messages in thread
From: Mario Hülsegge @ 2007-09-25 22:14 UTC (permalink / raw)
  To: netfilter

Am Sonntag, den 16.09.2007, 13:05 +0200 schrieb Pascal Hambourg:

> 
> > the problem is that it does not work. tcpdump gives me:
> > 
> > 00:28:00.461045 IP (tos 0x0, ttl  64, id 28447, offset 0, flags [DF], 
> > proto: UDP (17), length: 71) 192.168.0.125.1049 > vroot.domain: [udp sum 
> > ok]  62654+ PTR? 67.11.71.195.in-addr.arpa. (43)
> > 00:28:00.515190 IP (tos 0x0, ttl  56, id 0, offset 0, flags [DF], proto: 
> > UDP (17), length: 127) vroot.domain > 192.168.0.125.1049:  62654 NXDomain 
> > q: PTR? 67.11.71.195.in-addr.arpa. 0/1/0 ns: 71.195.in-addr.arpa. (99)
> > 00:28:01.459744 arp who-has 195.71.11.67 tell 192.168.0.125
> > 00:28:02.459844 arp who-has 195.71.11.67 tell 192.168.0.125
> 
> Was this trace captured on interface tun0 ?
 i am sorry, i confused the tcpdump output with another test on a normal
eth device, this is the capture on tun0:

23:47:54.378123 IP 192.168.0.125.3794 > ha-42.web.de.www: S
471744113:471744113(
0) win 5840 <mss 1460,sackOK,timestamp 7974928 0,nop,wscale 3>
23:47:57.377790 IP 192.168.0.125.3794 > ha-42.web.de.www: S
471744113:471744113(
0) win 5840 <mss 1460,sackOK,timestamp 7975678 0,nop,wscale 3>
23:48:03.378327 IP 192.168.0.125.3794 > ha-42.web.de.www: S
471744113:471744113(
0) win 5840 <mss 1460,sackOK,timestamp 7977178 0,nop,wscale 3>
23:48:15.379418 IP 192.168.0.125.3794 > ha-42.web.de.www: S
471744113:471744113(
0) win 5840 <mss 1460,sackOK,timestamp 7980178 0,nop,wscale 3>

the answer seems to be blocked in some way.. suggestions?


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-25 22:14   ` Mario Hülsegge
@ 2007-09-26 10:33     ` Pascal Hambourg
  2007-09-26 12:49       ` Mario Hülsegge
  0 siblings, 1 reply; 7+ messages in thread
From: Pascal Hambourg @ 2007-09-26 10:33 UTC (permalink / raw)
  To: netfilter

Mario Hülsegge a écrit :
> 
>  i am sorry, i confused the tcpdump output with another test on a normal
> eth device, this is the capture on tun0:
> 
> 23:47:54.378123 IP 192.168.0.125.3794 > ha-42.web.de.www: S 471744113:471744113(0) win 5840 <mss 1460,sackOK,timestamp 7974928 0,nop,wscale 3>
[etc.]
> the answer seems to be blocked in some way.. suggestions?

First, can you check on the VPN gateway that the request is received and 
forwarded to the destination server ?

Then, check the return path routing. One step would be to set the 
default route through the VPN and check that everything works well.

I see that your workstation source address, 192.168.0.125, is the same 
as in the capture on the ethernet device, and probably different from 
the tun0 address. This is normal, because the source address selection 
occurs before the port based routing is taken into account. However if 
the VPN gateway has no route to your source address, replies cannot come 
back. You may need to add an iptables SNAT or MASQUERADE rule for 
packets leaving the tun0 interface. Beware that with older kernels 
MASQUERADE may not work well with advanced routing.

Also, if the source address is a private address, the VPN gateway must 
perform SNAT or MASQUERADE on packets forwarded from the VPN to the 
public network.

Finally, check that /proc/sys/net/ipv4/conf/tun0/rp_filter = 0, else 
your workstation routing may drop the replies arriving at tun0 (although 
tcpdump would see them).

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-26 10:33     ` Pascal Hambourg
@ 2007-09-26 12:49       ` Mario Hülsegge
  2007-09-26 14:10         ` Pascal Hambourg
  0 siblings, 1 reply; 7+ messages in thread
From: Mario Hülsegge @ 2007-09-26 12:49 UTC (permalink / raw)
  To: Pascal Hambourg; +Cc: netfilter

Am Mittwoch, den 26.09.2007, 12:33 +0200 schrieb Pascal Hambourg:

> You may need to add an iptables SNAT or MASQUERADE rule for 
> packets leaving the tun0 interface. [...]
> 
> Finally, check that /proc/sys/net/ipv4/conf/tun0/rp_filter = 0, else 
> your workstation routing may drop the replies arriving at tun0 (although 
> tcpdump would see them).
> -

these 2 hints solved the problem, now all runs fine. i inserted a masq
rule before, but without setting rp_filter (who would ever thought of
THAT ;) ).

thank you very much for your help. 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Port-based routing with OpenVPN
  2007-09-26 12:49       ` Mario Hülsegge
@ 2007-09-26 14:10         ` Pascal Hambourg
  0 siblings, 0 replies; 7+ messages in thread
From: Pascal Hambourg @ 2007-09-26 14:10 UTC (permalink / raw)
  To: netfilter

Mario Hülsegge a écrit :
> 
> these 2 hints solved the problem, now all runs fine. i inserted a masq
> rule before, but without setting rp_filter

The kernel disables rp_filter by default, but the startup scripts 
provided by some distributions enable it.

> (who would ever thought of THAT ;) ).

The practical answer is : anyone who experienced the problem once does. 
Trust me.

The theoretical answer is : anyone using iproute should, because it is a 
common issue documented in the Linux Advanced Routing & Traffic Control 
HOWTO, and probably elsewhere. I myself hesitated to mention it and did 
it only for completeness because it could not be the only cause of your 
problem : tcpdump would have seen the replies even though the kernel had 
dropped them.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-09-26 14:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-15 23:15 (unknown) "Mario Hülsegge"
2007-09-16 11:05 ` Port-based routing with OpenVPN Pascal Hambourg
2007-09-19 21:38   ` Mario Hülsegge
2007-09-25 22:14   ` Mario Hülsegge
2007-09-26 10:33     ` Pascal Hambourg
2007-09-26 12:49       ` Mario Hülsegge
2007-09-26 14:10         ` Pascal Hambourg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox