<div dir="ltr"><div>I pushed:</div><div><br></div><div>commit d106052012c6a7b7a5d65e25e9c9fe0c32e34c1d (HEAD -> main, origin/main, origin/HEAD)<br>Author: Andrew Cagney <<a href="mailto:cagney@gnu.org">cagney@gnu.org</a>><br>Date: Wed Sep 23 19:36:49 2020 -0400<br><br> connections: call update_ends_from_this_host_addr() from connection_check_ddns1()<br> <br> Replace "a small bit of code from default_end to fixup the end point".<br> Except, once .host_port code is included, there are now three small<br> bits of code. Hmm, enemy action.<br> <br> A likely reason for not using default_end() was that, instead of<br> propagating the updated [remote] .host_addr into the peer's [local]<br> .host_nexthop, it did the reverse. update_ends_from_this_host_addr(),<br> which replaced default_end(), reversing this polarity.<br> <br> Remove (again) code updating .host_port in extract_end() - it doesn't<br> have complete information, and ends up setting the port on the %any<br> address.<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Sep 2020 at 10:33, Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com">andrew.cagney@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Yea, here's the relevant code (the encap comment is out-of-date):</div><div><br></div><div>static bool orient_new_iface_port(struct connection *c, struct fd *whackfd, bool this)</div><div> /*</div><div dir="ltr"> * assume UDP for now<br> *<br> * A custom IKEPORT should not float away to port 4500. For<br> * now leave ADD_IKE_ENCAPSULATION_PREFIX clear so it can talk<br> * to port 500. Perhaps it doesn't belong in iface?<br> */<br> struct iface_port *ifp = bind_iface_port(dev, &udp_iface_io,<br> ip_hport(end->raw.host.ikeport),<br> true/*esp_encapsulation_enabled*/,<br> false/*float_nat_initiator*/);</div><div dir="ltr"><div><br></div><div>Here are some random thoughts:</div><div><br></div><div>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:<br></div><div> lefttcpport=100</div><div> righttcpport=2000</div><div>open a tcp connection between LEFT:100 to RIGHT:2000. This could be a good thing?<br></div><div><br><div>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:<br></div><div> - UDP only on a custom port (not 500 and not 4500)</div><div> - TCP only on a custom port (not 4500)</div><div>(mumble something about {left,right}udpport).<br></div><div><br></div><div>Does listen-tcp=yes|no and listen-udp=yes|no only disable the default port?</div><div><br></div><div>Adding tcp-localport might be quickest. OTOH the udp equivalent was only just deleted.<br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Sep 2020 at 09:02, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 16 Sep 2020, Andrew Cagney wrote:<br>
<br>
> There is {left,right}ikeport?<br>
<br>
Yes, but it does not seem to affect TCP :)<br>
<br>
Paul<br>
<br>
> On Tue, 15 Sep 2020 at 22:48, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br>
><br>
> Some changes were made a while ago to the TCP port handling. You no<br>
> longer specify a port in 'config setup'. Instead there is<br>
> listen-tcp=yes|no and listen-udp=yes|no<br>
><br>
> For UDP, you can set custom ikeport's using leftikeport= and<br>
> rightikeport.<br>
><br>
> For TCP, you can set the port to connect to using tcp-remoteport=<br>
><br>
> But for the responder/server, we have no way now to specify a<br>
> non-default TCP port. Current default is 4500.<br>
><br>
> Should leftikeport/rightikeport be changed to also set the TCP<br>
> port? Or should we introduce a lefttcpikeport= and righttcpikeport= ?<br>
><br>
> Or should we add a config setup tcp-ports= option that defaults to 4500<br>
> but can be set to like 4500,443 ?<br>
><br>
> Note that we currently do not bind connections to ports. The connections<br>
> might open the specific port, but than any connection can use it. So<br>
> perhaps tcp-ports= is the easiest and cleanest solution ?<br>
><br>
> Paul<br>
> _______________________________________________<br>
> Swan-dev mailing list<br>
> <a href="mailto:Swan-dev@lists.libreswan.org" target="_blank">Swan-dev@lists.libreswan.org</a><br>
> <a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
> <br>
> <br>
><br>
</blockquote></div></div>
</blockquote></div>