* Routing issue
@ 2021-03-06 19:12 Florin Vlaicu
[not found] ` <CAOAVeL0mxeXGJXs6idBXyi8ibVvJ2d3qAtEo2Yd2Bby37zQ1RQ@mail.gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Florin Vlaicu @ 2021-03-06 19:12 UTC (permalink / raw)
To: wireguard
I am running a server in a container that uses a macvlan interface to
have a static IP address in my local LAN. Then from my router I DNAT
to that IP address.
If I stop the container and then start it on another host (with the
exact same configuration) existing tunnels will fail, but new ones
will work.
If I just restart the container (or even reboot the host) the existing
tunnels will come back up.
Is there something I can change on the clients to not have to restart
the tunnel?
Thanks,
Florin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing issue
[not found] ` <CAOAVeL0mxeXGJXs6idBXyi8ibVvJ2d3qAtEo2Yd2Bby37zQ1RQ@mail.gmail.com>
@ 2021-03-09 7:21 ` Florin Vlaicu
0 siblings, 0 replies; 6+ messages in thread
From: Florin Vlaicu @ 2021-03-09 7:21 UTC (permalink / raw)
To: wireguard
In the meantime I was able to debug and fix this issue with the help
of the IRC channel.
It turns out the container on the other host had different mac
addresses as soon as I synced them things started working.
Thanks,
Florin
On Tue, Mar 9, 2021 at 8:55 AM Henning Reich <henningreich@gmail.com> wrote:
>
> Have you check time/timezone and wait enough time to clean/rebuild arp caches?
>
> Florin Vlaicu <florin@vlaicu.com> schrieb am So. 7. März 2021 um 18:26:
>>
>> I am running a server in a container that uses a macvlan interface to
>> have a static IP address in my local LAN. Then from my router I DNAT
>> to that IP address.
>> If I stop the container and then start it on another host (with the
>> exact same configuration) existing tunnels will fail, but new ones
>> will work.
>> If I just restart the container (or even reboot the host) the existing
>> tunnels will come back up.
>> Is there something I can change on the clients to not have to restart
>> the tunnel?
>>
>> Thanks,
>> Florin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Routing issue
@ 2012-09-26 11:01 Stephen Clark
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Clark @ 2012-09-26 11:01 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hello,
Because Linux makes routing decisions before SNAT it is causing
problems when trying to use FTP with two upstream providers in
a load balanced setup.
Other than ftp things seem to work OK. Below is my setup and tcpdump
output that shows ftp packets trying to go out the wrong interface.
ip ru sh
0: from all lookup local
200: from y.y.y.174 lookup t1
201: from x.x.x.217 lookup t2
32766: from all lookup main
32767: from all lookup default
ip r s
y.y.y.129 dev eth1 scope link
172.16.0.0/29 dev gre1 proto kernel scope link src 172.16.0.1
y.y.y.128/25 dev eth1 proto kernel scope link src y.y.y.174
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.90
192.168.198.0/24 dev eth0 proto kernel scope link src 192.168.198.92
x.x.x.0/24 dev eth2 proto kernel scope link src x.x.x.217
10.0.128.0/17 dev eth0 proto kernel scope link src 10.0.129.88
default
nexthop via y.y.y.129 dev eth1 weight 1
nexthop via x.x.x.1 dev eth2 weight 1
ip r s tab t1
default via y.y.y.129 dev eth1 src y.y.y.174
ip r s tab t2
default via x.x.x.1 dev eth2 src x.x.x.217
Chain PREROUTING (policy ACCEPT 1050K packets, 128M bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 423K packets, 35M bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * eth1 10.0.1.0/24
10.0.0.0/8
0 0 ACCEPT all -- * eth1 10.0.1.0/24
172.16.0.0/12
0 0 ACCEPT all -- * eth1 10.0.1.0/24
192.168.0.0/16
58 3480 SNAT all -- * eth1 10.0.1.0/24
0.0.0.0/0 to:y.y.y.174
4 240 SNAT all -- * eth2 10.0.1.0/24
0.0.0.0/0 to:x.x.x.217
lsmod | grep nf_
nf_conntrack_ipv6 7207 3
nf_defrag_ipv6 9873 1 nf_conntrack_ipv6
nf_nat_ftp 2602 0
nf_nat 18580 2 iptable_nat,nf_nat_ftp
nf_conntrack_ipv4 7694 6 iptable_nat,nf_nat
nf_defrag_ipv4 1039 1 nf_conntrack_ipv4
nf_conntrack_ftp 10475 1 nf_nat_ftp
nf_conntrack 65524 7
iptable_nat,nf_conntrack_ipv6,xt_state,nf_nat_ftp,nf_nat,nf_conntrack_ipv4,nf_conntrack_ftp
ipv6 264769 41
nf_conntrack_ipv6,nf_defrag_ipv6,ip6table_mangle,ip6_tunnel,tunnel6
connection starts out eth2 - but then subsequent packets that should be
routed out eth2 are being sent out eth1 see below.
eth2 x.x.x.217
tcpdump -nli eth2 host 131.247.254.5
16:23:06.062451 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [S], seq
1482565198, win 5840, options [mss 1460,sackOK,TS val 423546705 ecr
0,nop,wscale 6], length 0
16:23:06.076788 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [S.], seq
740341460, ack 1482565199, win 5792, options [mss 1460,sackOK,TS val
2565444838 ecr 423546705,nop,wscale 7], length 0
16:23:06.077224 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423546720 ecr 2565444838], length 0
16:23:06.096900 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565444858 ecr 423546720],
length 96
16:23:06.316866 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565445077 ecr 423546720],
length 96
16:23:06.764410 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565445515 ecr 423546720],
length 96
16:23:07.634411 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565446391 ecr 423546720],
length 96
16:23:09.394482 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565448143 ecr 423546720],
length 96
16:23:12.886997 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565451647 ecr 423546720],
length 96
16:23:19.892082 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565458655 ecr 423546720],
length 96
16:23:33.907303 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565472671 ecr 423546720],
length 96
16:24:01.935273 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565500703 ecr 423546720],
length 96
16:24:57.993631 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565556767 ecr 423546720],
length 96
16:26:50.107951 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [P.], seq
1:97, ack 1, win 46, options [nop,nop,TS val 2565668895 ecr 423546720],
length 96
16:28:06.104031 IP 131.247.254.5.ftp > x.x.x.217.53651: Flags [FP.], seq
97:111, ack 1, win 46, options [nop,nop,TS val 2565744900 ecr
423546720], length 14
These packets should be going out eth2 not eth1
eth1 y.y.y.174
tcpdump -pnli eth1 host 131.247.254.5
16:23:06.097415 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
740341557, win 92, options [nop,nop,TS val 423546741 ecr 2565444858],
length 0
16:23:06.317381 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423546961 ecr 2565445077,nop,nop,sack
1 {4294967201:1}], length 0
16:23:06.764908 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423547408 ecr 2565445515,nop,nop,sack
1 {4294967201:1}], length 0
16:23:07.634894 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423548278 ecr 2565446391,nop,nop,sack
1 {4294967201:1}], length 0
16:23:09.394972 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423550038 ecr 2565448143,nop,nop,sack
1 {4294967201:1}], length 0
16:23:12.887529 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423553531 ecr 2565451647,nop,nop,sack
1 {4294967201:1}], length 0
16:23:19.892616 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423560536 ecr 2565458655,nop,nop,sack
1 {4294967201:1}], length 0
16:23:33.907736 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423574551 ecr 2565472671,nop,nop,sack
1 {4294967201:1}], length 0
16:23:40.173991 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423580817 ecr 2565472671],
length 13
16:23:40.388692 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423581032 ecr 2565472671],
length 13
16:23:40.819714 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423581463 ecr 2565472671],
length 13
16:23:41.680729 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423582324 ecr 2565472671],
length 13
16:23:43.404732 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423584048 ecr 2565472671],
length 13
16:23:46.852787 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423587496 ecr 2565472671],
length 13
16:23:53.756879 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423594400 ecr 2565472671],
length 13
16:24:01.935822 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423602578 ecr 2565500703,nop,nop,sack
1 {4294967201:1}], length 0
16:24:07.549037 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423608192 ecr 2565500703],
length 13
16:24:35.133346 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423635776 ecr 2565500703],
length 13
16:24:57.994150 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423658636 ecr 2565556767,nop,nop,sack
1 {4294967201:1}], length 0
16:25:30.365963 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423691008 ecr 2565556767],
length 13
16:26:50.108488 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [.], ack
1, win 92, options [nop,nop,TS val 423770749 ecr 2565668895,nop,nop,sack
1 {4294967201:1}], length 0
16:27:20.703243 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [P.], seq
0:13, ack 1, win 92, options [nop,nop,TS val 423801344 ecr 2565668895],
length 13
16:28:06.104578 IP x.x.x.217.53651 > 131.247.254.5.ftp: Flags [F.], seq
13, ack 16, win 92, options [nop,nop,TS val 423846744 ecr 2565744900],
length 0
Is there a way to make this work correctly?
Thanks,
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* Routing issue
@ 2003-08-29 18:46 Reinaldo Brandão Gomes
0 siblings, 0 replies; 6+ messages in thread
From: Reinaldo Brandão Gomes @ 2003-08-29 18:46 UTC (permalink / raw)
To: linux-kernel
Thanks, Ray
For I have been told that trying NATing on a Linux SuSE sparc arch is not a good idea, as a friend had crashed its system repeated times trying to do it, besides there are some security issues related to NAT, I decided to update the routing table on the remote end
The point is that to do so, to route the 172.18.1.0 back to 192.168.14.0 using the INTRANET server (172.16.8.51) as gateway it (the INTRANET server) would need to have an IP address on the 172.18.1.0 subnet.
Traceroute from 172.18.1.204 to 172.16.8.51 gives:
Traceroute to 172.16.8.51 (172.16.8.51), 30 hops max, 40 byte packets 1 172.18.1.68 (172.18.1.68) 0.506 ms 0.422 ms 2.939 ms 2 172.18.1.1 (172.18.1.1) 1.991 ms 3.035 ms 3.167 ms 3 192.168.42.1 (192.168.42.1) 13.844 ms 10.905 ms 2.516 ms 4 192.168.43.1 (192.168.43.1) 9.808 ms 92.118 ms 26.526 ms 5 172.16.8.51 (172.16.8.51) 81.256 ms 115.822 ms 19.080 ms
My question now is: HOW can I find out what would be the INTRANET server (172.16.8.51) IP address on 172.18.1.0 subnet (if any) or is there any other way to route 172.18.1.0 back to 192.168.14.0?
Responses are really appreciated.
Reinaldo
-----Mensagem original-----
De: Ray Olszewski [mailto:ray@comarre.com]
Enviada em: quinta-feira, 28 de agosto de 2003 15:44
Para: Reinaldo Brandão Gomes
Assunto: Re: ENC: Routing issue
The obvious question: is boavista NATing the 192.168.14.0/24 network or
simply routing it? If the second, the most likely source of your problem is
that the remote router (172.16.8.51) does not know that boavista's ppp IP
address (172.16.8.63, I think) is its route to network 192.168.14.0/24 . To
fix this, either update the routing table on the remote end or NAT the
local LAN.
At 02:20 PM 8/28/2003 -0300, Reinaldo Brandão Gomes wrote:
>Hi, ray
>
>Just got your email from google. Really hope you can help me here.
>
>
>I am trying to create a connection from our office to a client net.
>
>What I want to do is showed in the following line:
>
>192.168.14.10 --etho-> 192.168.14.11 --ppp0--> 172.16.8.51 --eth0-->
>172.18.1.0 (dispatch net in Itabira)
> (bviagem) (boavista) (client
> intranet) client servers
>
>I have created a dialup connection from 192.168.14.11 (sparc_linux
>suse)
>to 172.16.8.51 (Client intranet server), using wvdial. After connecting to
>172.16.8.51, I run, in 192.168.14.11:
>
>Route add -net 172.18.1.0 gateway 172.16.51 dev ppp0
>
>And can ping, telnet, rsh the clients servers in Itabira from
>192.168.14.11.
>
>So far so good.
>
>After that I ran
>
>
>192.168.14.11(boavista) is Linux, and its kernel supports ip_forward.
>
>echo "1" > /proc/sys/net/ipv4/ip_forward in boavista, then
>
>cat /proc/sys/net/ipv4/ip_forward returns 1
>
>In 192.168.14.10 (bviagem - Unix), after route add -net 172.18.1.0
>192.168.14.11, netstat -r shows:
>
>Routing Table:
> Destination Gateway Flags Ref Use Interface
>-------------------- -------------------- ----- ----- ------ ---------
>172.18.1.0 boavista.vpn.mmsi.com UGH 0 0
>192.168.14.0 bviagem U 3 16 hme0
>172.18.1.0 boavista.vpn.mmsi.com UG 0 4
>base-address.mcast.net bviagem U 3 0 hme0
>default 192.168.14.1 UG 0 25
>localhost localhost UH 0 3 lo0
>
>Ifconfig in boavista shows:
>
>eth0 Link encap:Ethernet HWaddr 08:00:20:F8:54:28
> inet addr:192.168.14.11 Bcast:192.168.14.255 Mask:255.255.255.0
> inet6 addr: fe80::a00:20ff:fef8:5428/10 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:32792 errors:0 dropped:0 overruns:0 frame:0
> TX packets:32484 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:2228241 (2.1 Mb) TX bytes:12791952 (12.1 Mb)
> Interrupt:32 Base address:0x6000
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:61363 errors:0 dropped:0 overruns:0 frame:0
> TX packets:61363 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:12463074 (11.8 Mb) TX bytes:12463074 (11.8 Mb)
>
>ppp0 Link encap:Point-to-Point Protocol
> inet addr:172.16.8.63 P-t-P:172.16.8.51 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1600 Metric:1
> RX packets:1937 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2020 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:162484 (158.6 Kb) TX bytes:169357 (165.3 Kb)
>
>
>I can ping 172.18.1.204 (client server) from boavista, but a ping
>172.18.1.204 from bviagem fails:
>
>NO answer from 172.18.1.204.
>
>Can you see what I am missing here?
>
>Thanks,
>
>Reinaldo
.'.
Linux /V\
Dont Fear The Penguin // \\
rbgomes@mmsi.com /( )\
^^-^^
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: routing issue
@ 2001-11-26 17:55 Julian Anastasov
0 siblings, 0 replies; 6+ messages in thread
From: Julian Anastasov @ 2001-11-26 17:55 UTC (permalink / raw)
To: Hisham Kotry; +Cc: linux-kernel, ja
Hello,
Hisham Kotry wrote:
> I have been trying to find a direct kernel hack that
> forces the linux kernel -any version- to use
> postrouting instead of prerouting, I have my reasons
> why I do not want to use netfilter, I currently use
> another FW, but I have this problem with routing, is
> there a way to fix it?
There are some issues with netfilter+routing but it depends on
your setup. There are patches for this. You have to explain your
problem with the routing because Netfilter uses both pre- and
post-routing for different things. Your statement is ambigous. Do
you mean using the filtering in post_routing or what? I assume it
should be something with NAT but better you to explain.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply [flat|nested] 6+ messages in thread
* routing issue
@ 2001-11-26 11:56 Hisham Kotry
0 siblings, 0 replies; 6+ messages in thread
From: Hisham Kotry @ 2001-11-26 11:56 UTC (permalink / raw)
To: linux-kernel
I have been trying to find a direct kernel hack that
forces the linux kernel -any version- to use
postrouting instead of prerouting, I have my reasons
why I do not want to use netfilter, I currently use
another FW, but I have this problem with routing, is
there a way to fix it?
Thanks,
etsh911
PS: please CC the replies to me, as I am not a
subscriber to this list.
__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-03-09 21:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-06 19:12 Routing issue Florin Vlaicu
[not found] ` <CAOAVeL0mxeXGJXs6idBXyi8ibVvJ2d3qAtEo2Yd2Bby37zQ1RQ@mail.gmail.com>
2021-03-09 7:21 ` Florin Vlaicu
-- strict thread matches above, loose matches on Subject: below --
2012-09-26 11:01 Stephen Clark
2003-08-29 18:46 Reinaldo Brandão Gomes
2001-11-26 17:55 routing issue Julian Anastasov
2001-11-26 11:56 Hisham Kotry
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.