[Swan-dev] leftikeport= does not set tcp port

[Andrew Cagney]

I pushed:

commit d106052012c6a7b7a5d65e25e9c9fe0c32e34c1d (HEAD -> main, origin/main,
origin/HEAD)
Author: Andrew Cagney <cagney at gnu.org>
Date:   Wed Sep 23 19:36:49 2020 -0400

    connections: call update_ends_from_this_host_addr() from
connection_check_ddns1()

    Replace "a small bit of code from default_end to fixup the end point".
    Except, once .host_port code is included, there are now three small
    bits of code.  Hmm, enemy action.

    A likely reason for not using default_end() was that, instead of
    propagating the updated [remote] .host_addr into the peer's [local]
    .host_nexthop, it did the reverse.  update_ends_from_this_host_addr(),
    which replaced default_end(), reversing this polarity.

    Remove (again) code updating .host_port in extract_end() - it doesn't
    have complete information, and ends up setting the port on the %any
    address.



On Wed, 16 Sep 2020 at 10:33, Andrew Cagney <andrew.cagney at gmail.com> wrote:

> Yea, here's the relevant code (the encap comment is out-of-date):
>
> static bool orient_new_iface_port(struct connection *c, struct fd
> *whackfd, bool this)
>         /*
>          * assume UDP for now
>          *
>          * A custom IKEPORT should not float away to port 4500.  For
>          * now leave ADD_IKE_ENCAPSULATION_PREFIX clear so it can talk
>          * to port 500.  Perhaps it doesn't belong in iface?
>          */
>         struct iface_port *ifp = bind_iface_port(dev, &udp_iface_io,
>
>  ip_hport(end->raw.host.ikeport),
>
>  true/*esp_encapsulation_enabled*/,
>
>  false/*float_nat_initiator*/);
>
> Here are some random thoughts:
>
> I  think {left,right}tcpport would be a better name than
> {left,right}tcpikeport - all traffic, not just ike, will flow through it.
> However, for the sake of consistency, we'll want to have:
>     lefttcpport=100
>     righttcpport=2000
> open a tcp connection between LEFT:100 to RIGHT:2000.  This could be a
> good thing?
>
> I've a hunch that overloading {left,right}ikeport will come back to haunt
> us.  In addition to the above consistency, I suspect it will cause problems
> with configurations such as:
>   - UDP only on a custom port (not 500 and not 4500)
>   - TCP only on a custom port (not 4500)
> (mumble something about {left,right}udpport).
>
> Does listen-tcp=yes|no and listen-udp=yes|no only disable the default port?
>
> Adding tcp-localport might be quickest.  OTOH the udp equivalent was only
> just deleted.
>
>
> On Wed, 16 Sep 2020 at 09:02, Paul Wouters <paul at nohats.ca> wrote:
>
>> On Wed, 16 Sep 2020, Andrew Cagney wrote:
>>
>> > There is {left,right}ikeport?
>>
>> Yes, but it does not seem to affect TCP :)
>>
>> Paul
>>
>> > On Tue, 15 Sep 2020 at 22:48, Paul Wouters <paul at nohats.ca> wrote:
>> >
>> >       Some changes were made a while ago to the TCP port handling. You
>> no
>> >       longer specify a port in 'config setup'. Instead there is
>> >       listen-tcp=yes|no and listen-udp=yes|no
>> >
>> >       For UDP, you can set custom ikeport's using leftikeport= and
>> >       rightikeport.
>> >
>> >       For TCP, you can set the port to connect to using tcp-remoteport=
>> >
>> >       But for the responder/server, we have no way now to specify a
>> >       non-default TCP port. Current default is 4500.
>> >
>> >       Should leftikeport/rightikeport be changed to also set the TCP
>> >       port? Or should we introduce a lefttcpikeport= and
>> righttcpikeport= ?
>> >
>> >       Or should we add a config setup tcp-ports= option that defaults
>> to 4500
>> >       but can be set to like 4500,443 ?
>> >
>> >       Note that we currently do not bind connections to ports. The
>> connections
>> >       might open the specific port, but than any connection can use it.
>> So
>> >       perhaps tcp-ports= is the easiest and cleanest solution ?
>> >
>> >       Paul
>> >       _______________________________________________
>> >       Swan-dev mailing list
>> >       Swan-dev at lists.libreswan.org
>> >       https://lists.libreswan.org/mailman/listinfo/swan-dev
>> >
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200924/6be1cbc3/attachment.html>