From: Antony Antony <antony@phenome.org>
To: Michael Richardson <mcr@sandelman.ca>
Cc: antony.antony@secunet.com,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org, devel@linux-ipsec.org,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [devel-ipsec] [PATCH v2 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway
Date: Sun, 29 Oct 2023 11:26:26 +0100 [thread overview]
Message-ID: <ZT4zUnhvbW2VZlRm@Antony2201.local> (raw)
In-Reply-To: <16810.1698413407@localhost>
On Fri, Oct 27, 2023 at 09:30:07AM -0400, Michael Richardson via Devel wrote:
>
> Antony Antony via Devel <devel@linux-ipsec.org> wrote:
> > When enabling support for xfrm lookup using reverse ICMP payload,
> > We have identified an issue where the source address of the IPv4 e.g
> > "Destination Host Unreachable" message is incorrect. The IPv6 appear
> > to do the right thing.
>
> One thing that operators of routers with a multitude of interfaces want to do
> is send all ICMP messages from a specific IP address. Often the public
> address, that has the sane reverse DNS name.
While it makes sense for routers with multiple interfaces, receiving ICMP
errors from private addresses can be confusing. However, wouldn't this also
make it more challenging to adhere to BCP 32 and BCP 38? Routing with
multiple interfaces is tricky on Linux, especially when it comes to
compliance with these BCPs.
> AFAIK, this is not an option on Linux, but Cisco/Juniper/etc. devices usually
> can do this. I can't recall how today. (I was actually looking that up this week)
I wonder if a netfilter rule would be a solution for you, something like:
"ip protocol icmp type <error codes> snat to x.x.x.x"
I would love see a simple option instead of a SNAT hack. May be a routing
rule that will choose sourse address for ICMP error code.
> This can conflict however, with the need to get the result back into the
> tunnel. I don't have a good answer, except that we probably need a fair bit
Forwarding that ICMP packet, which is not covered by your forward IPsec
policy, would be fixed with the second patch in this series. In that case
lookup would using the orginal packet as describe in RFC 4301, Section 6.
-antony
next prev parent reply other threads:[~2023-10-29 10:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <YTXGGiMzsda6mcm2@AntonyAntony.local>
2021-12-19 0:28 ` [RFC PATCH ipsec-next] xfrm: add forwarding ICMP error message Antony Antony
2023-10-26 14:45 ` [PATCH ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-10-26 19:41 ` kernel test robot
2024-01-30 10:36 ` Dan Carpenter
2024-01-31 19:38 ` Antony Antony
2024-01-31 19:48 ` Dan Carpenter
2024-01-31 19:50 ` Dan Carpenter
2023-10-26 14:45 ` [PATCH ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27 8:16 ` [PATCH v2 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-11-17 9:13 ` Steffen Klassert
2023-11-25 22:48 ` [devel-ipsec] " Antony Antony
2023-10-27 8:16 ` [PATCH v2 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27 13:30 ` [devel-ipsec] " Michael Richardson
2023-10-29 10:26 ` Antony Antony [this message]
2023-10-31 7:59 ` Michael Richardson
2023-11-17 9:21 ` Steffen Klassert
2023-11-25 23:15 ` [devel-ipsec] " Antony Antony
2023-12-19 20:29 ` [PATCH v3 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-19 20:30 ` [PATCH v3 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-21 13:12 ` [PATCH v4 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-21 13:12 ` [PATCH v4 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-22 7:23 ` Steffen Klassert
2023-12-22 12:56 ` Antony Antony
2023-12-22 12:57 ` [PATCH v5 ipsec-next] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2024-01-04 9:39 ` Steffen Klassert
2024-01-19 11:27 ` [PATCH v6 " Antony Antony
2024-01-26 9:11 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZT4zUnhvbW2VZlRm@Antony2201.local \
--to=antony@phenome.org \
--cc=antony.antony@secunet.com \
--cc=davem@davemloft.net \
--cc=devel@linux-ipsec.org \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=mcr@sandelman.ca \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).