Re: Syspatch https://cdn.openbsd.org/pub/OpenBSD
accessible via my T-Mobile phone On July 12, 2023 5:04:21 PM MDT, Chris Narkiewicz wrote: >On Wed, Jul 12, 2023 at 03:19:17PM -0700, latin...@vcn.bc.ca wrote: >> Is it working? >> https://cdn.openbsd.org/pub/OpenBSD > >Works for me. > >Best regards, >Chris Narkiewicz >
Re: Syspatch https://cdn.openbsd.org/pub/OpenBSD
On Wed, Jul 12, 2023 at 03:19:17PM -0700, latin...@vcn.bc.ca wrote: > Is it working? > https://cdn.openbsd.org/pub/OpenBSD Works for me. Best regards, Chris Narkiewicz
Syspatch https://cdn.openbsd.org/pub/OpenBSD
Hello misc Is it working? https://cdn.openbsd.org/pub/OpenBSD # syspatch syspatch: cdn.openbsd.org: no address associated with name Thanks
Re: Weird cvs diff of recent httpd changes on OPENBSD_7_2 branch
On Wed, Jul 12, 2023 at 06:28:47PM +0200, Matthias Pressfreund wrote: > Why does 'cvs diff -D...' on the OPENBSD_7_2 branch > include changes from before the given date? Because cvs -D resolves to the most recent revision no later than the given date, and the OPENBSD_7_2 tag contains files that were not modified since OPENBSD_7_1. For instance, config.c has the same revision in OPENBSD_7_1 and OPENBSD_7_2. The latest change to that file on the OPENBSD_7_2 branch, no newer than -D2023-07-11, happened before 7.1 was tagged. There is a newer config.c change on HEAD and OPENBSD_7_3 but you won't see that change in a working copy checked out with -rOPENBSD_7_2.
Weird cvs diff of recent httpd changes on OPENBSD_7_2 branch
Why does 'cvs diff -D...' on the OPENBSD_7_2 branch
include changes from before the given date?
# cvs -qd anon...@anoncvs.spacehopper.org:/cvs checkout -rOPENBSD_7_2 -P
src/usr.sbin/httpd
U src/usr.sbin/httpd/Makefile
U src/usr.sbin/httpd/config.c
U src/usr.sbin/httpd/control.c
U src/usr.sbin/httpd/http.h
U src/usr.sbin/httpd/httpd.8
U src/usr.sbin/httpd/httpd.c
U src/usr.sbin/httpd/httpd.conf.5
U src/usr.sbin/httpd/httpd.h
U src/usr.sbin/httpd/log.c
U src/usr.sbin/httpd/logger.c
U src/usr.sbin/httpd/parse.y
U src/usr.sbin/httpd/patterns.7
U src/usr.sbin/httpd/patterns.c
U src/usr.sbin/httpd/patterns.h
U src/usr.sbin/httpd/proc.c
U src/usr.sbin/httpd/server.c
U src/usr.sbin/httpd/server_fcgi.c
U src/usr.sbin/httpd/server_file.c
U src/usr.sbin/httpd/server_http.c
# cd src
# cvs diff -uNp -D2023-07-11 usr.sbin/httpd/*
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.63
retrieving revision 1.62
diff -u -p -u -p -r1.63 -r1.62
--- usr.sbin/httpd/config.c 28 Dec 2022 21:30:16 - 1.63
+++ usr.sbin/httpd/config.c 24 Oct 2021 16:01:04 - 1.62
@@ -1,4 +1,4 @@
-/* $OpenBSD: config.c,v 1.63 2022/12/28 21:30:16 jmc Exp $ */
+/* $OpenBSD: config.c,v 1.62 2021/10/24 16:01:04 ian Exp $ */
/*
* Copyright (c) 2011 - 2015 Reyk Floeter
@@ -233,7 +233,7 @@ config_setserver(struct httpd *env, stru
return (-1);
}
- /* Configure FCGI parameters if necessary. */
+ /* Configure FCGI parmeters if necessary. */
config_setserver_fcgiparams(env, srv);
}
}
Index: usr.sbin/httpd/control.c
===
RCS file: /cvs/src/usr.sbin/httpd/control.c,v
retrieving revision 1.15
retrieving revision 1.14
diff -u -p -u -p -r1.15 -r1.14
--- usr.sbin/httpd/control.c8 Mar 2023 04:43:13 - 1.15
+++ usr.sbin/httpd/control.c20 Apr 2021 21:11:56 - 1.14
@@ -1,4 +1,4 @@
-/* $OpenBSD: control.c,v 1.15 2023/03/08 04:43:13 guenther Exp $ */
+/* $OpenBSD: control.c,v 1.14 2021/04/20 21:11:56 dv Exp $ */
/*
* Copyright (c) 2003, 2004 Henning Brauer
@@ -127,6 +127,7 @@ control_cleanup(struct control_sock *cs)
event_del(>cs_evt);
}
+/* ARGSUSED */
void
control_accept(int listenfd, short event, void *arg)
{
@@ -213,6 +214,7 @@ control_close(int fd, struct control_soc
free(c);
}
+/* ARGSUSED */
void
control_dispatch_imsg(int fd, short event, void *arg)
{
Index: usr.sbin/httpd/httpd.8
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.8,v
retrieving revision 1.54
retrieving revision 1.53
diff -u -p -u -p -r1.54 -r1.53
--- usr.sbin/httpd/httpd.8 24 Oct 2022 15:02:01 - 1.54
+++ usr.sbin/httpd/httpd.8 15 Sep 2016 20:57:07 - 1.53
@@ -1,4 +1,4 @@
-.\"$OpenBSD: httpd.8,v 1.54 2022/10/24 15:02:01 jmc Exp $
+.\"$OpenBSD: httpd.8,v 1.53 2016/09/15 20:57:07 jmc Exp $
.\"
.\" Copyright (c) 2014 Reyk Floeter
.\"
@@ -14,7 +14,7 @@
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
-.Dd $Mdocdate: October 24 2022 $
+.Dd $Mdocdate: September 15 2016 $
.Dt HTTPD 8
.Os
.Sh NAME
@@ -75,6 +75,10 @@ Default configuration file.
Default SSL/TLS server key.
.It Pa /etc/ssl/server.crt
Default SSL/TLS server certificate.
+.It Pa /var/run/httpd.sock
+.Ux Ns -domain
+socket used for communication with
+.Nm .
.It Pa /var/www/logs/access.log
Default access log file.
.It Pa /var/www/logs/error.log
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.162
retrieving revision 1.161.2.1
diff -u -p -u -p -r1.162 -r1.161.2.1
--- usr.sbin/httpd/httpd.h 24 Oct 2022 15:02:01 - 1.162
+++ usr.sbin/httpd/httpd.h 12 Jul 2023 12:46:33 - 1.161.2.1
@@ -1,4 +1,4 @@
-/* $OpenBSD: httpd.h,v 1.162 2022/10/24 15:02:01 jmc Exp $ */
+/* $OpenBSD: httpd.h,v 1.161.2.1 2023/07/12 12:46:33 tb Exp $ */
/*
* Copyright (c) 2006 - 2015 Reyk Floeter
@@ -44,6 +44,7 @@
#endif
#define CONF_FILE "/etc/httpd.conf"
+#define HTTPD_SOCKET "/var/run/httpd.sock"
#define HTTPD_USER "www"
#define HTTPD_SERVERNAME "OpenBSD httpd"
#define HTTPD_DOCROOT "/htdocs"
@@ -352,6 +353,7 @@ struct client {
int clt_inflight;
struct range_dataclt_ranges;
struct fcgi_data clt_fcgi;
+ const char *clt_fcgi_error;
char*clt_remote_user;
struct evbuffer *clt_srvevb;
Index: usr.sbin/httpd/proc.c
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
LOL, fair enough. Feel free to yell at me for this third question and tell me to start a new thread. How do you recommend I should proceed in diagnosing these "ndp info overwritten" messages? It seems bizarre they started out of nowhere. Before May 2, I didn't have any; but since, I get them every 90 minutes or so. There is nothing that stands out in my logs that would suggest it was a software, hardware, or configuration change on my end. I changed hardware in March. I upgraded to OpenBSD 7.3 in late April. The first patch for 7.3 was a day after the first message. I upgraded my BIOS/UEFI in June. I haven't changed my DOCSIS 3.1 modem. There were no reboots around that time. I am still with the same ISP. I found this from @bugs: https://marc.info/?l=openbsd-bugs=165130576328299=2 but I have always had "allow-opts" for both ingress and egress ICMPv6 traffic, so Otto Moerbeek's workaround is not applicable. I tried the opposite (i.e., removing "allow-opts") as a shot in the dark, and it unsurprisingly didn't fix the problem (assuming there is one). I do recall helping the maintainer/creator of my DHCPv6 client, dhcpcd, around that time fix some other bugs; however my logs show that was a few hours after the first "ndp info overwritten" message. Nonetheless, I temporarily replaced the current version of dhcpcd which contains several bug fixes with the older version that is part of the -release packages. Even with that version, I was still getting these messages. Can you provide any guidance?
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On Wed, Jul 12, 2023 at 10:59:13AM -0600, Zack Newman wrote: > On 7/12/23 10:20, Claudio Jeker wrote: > > You are missing something. It is called the KAME hack or embedded scope. > > The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the > > scope_id. In some cases this embedded scope escapes in the addrs printed. > > Especially the "ndp info overwritten for" is leaking the scope_id (4) > > which is probably the interface index of your em0 interface. > > > > Welcome to IPv6, the world would be better without all the garbage. > > As predicted, em0 does in fact have index 4. Follow up question. Am I > to interpret this as purely a display problem and not a functional one? Depends. It is mostly a display issue until it isn't. The above is a display issue. > If so, can you explain why when I have the following rule in pf.conf(5): > > block out quick on $wan inet6 to fe80:4::c6ca:2bff:fe5a:8723%em0 > > I am still able to ping6(8) it: > > router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 > PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 > data bytes > 64 bytes from fe80::c6ca:2bff:fe5a:8723%em0: icmp_seq=0 hlim=64 time=7.294 ms > > --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 7.294/7.294/7.294/0.000 ms > > meanwhile if I remove the "4", I am unable to ping6(8) it?: Because the two addresses are not the same (in some cases). Confusing? Yes it is. > router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 > PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 > data bytes > ping6: sendmsg: Permission denied > ping: wrote fe80:4::c6ca:2bff:fe5a:8723%em0 64 chars, ret=-1 > > --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > > I should add that I can replace the second octet pair with any non-zero > value, and I am unable to block it. Asked differently, how would I be > able to block traffic to/from fe80:4::c6ca:2bff:fe5a:8723%em0 while > still allowing traffic to/from fe80::c6ca:2bff:fe5a:8723%em0 where "4" > is interpreted as not the scope_id but in fact part of the address since > seemingly "%em0" is sufficient without scope_id? You can't (they are the same). -- :wq Claudio
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On 7/12/23 10:20, Claudio Jeker wrote: You are missing something. It is called the KAME hack or embedded scope. The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the scope_id. In some cases this embedded scope escapes in the addrs printed. Especially the "ndp info overwritten for" is leaking the scope_id (4) which is probably the interface index of your em0 interface. Welcome to IPv6, the world would be better without all the garbage. As predicted, em0 does in fact have index 4. Follow up question. Am I to interpret this as purely a display problem and not a functional one? If so, can you explain why when I have the following rule in pf.conf(5): block out quick on $wan inet6 to fe80:4::c6ca:2bff:fe5a:8723%em0 I am still able to ping6(8) it: router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data bytes 64 bytes from fe80::c6ca:2bff:fe5a:8723%em0: icmp_seq=0 hlim=64 time=7.294 ms --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 7.294/7.294/7.294/0.000 ms meanwhile if I remove the "4", I am unable to ping6(8) it?: router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data bytes ping6: sendmsg: Permission denied ping: wrote fe80:4::c6ca:2bff:fe5a:8723%em0 64 chars, ret=-1 --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss I should add that I can replace the second octet pair with any non-zero value, and I am unable to block it. Asked differently, how would I be able to block traffic to/from fe80:4::c6ca:2bff:fe5a:8723%em0 while still allowing traffic to/from fe80::c6ca:2bff:fe5a:8723%em0 where "4" is interpreted as not the scope_id but in fact part of the address since seemingly "%em0" is sufficient without scope_id?
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On Wed, Jul 12, 2023 at 08:23:36AM -0600, Zack Newman wrote: > Before I raise a bug report, I wanted to pass it by @misc in case I'm > confused. It appears there is an issue with link-local addresses at > least as far as route(8) is concerned. Since May 2, /var/log/messages > has been getting spammed with the following: > > router$ tail -6 /var/log/messages > Jul 12 03:02:47 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 > Jul 12 03:02:51 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 > Jul 12 04:57:30 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:8723 by c4:ca:2b:5a:87:23 on em0 > Jul 12 04:57:34 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:8723 by 00:1c:73:00:00:99 on em0 > Jul 12 06:16:31 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 > Jul 12 06:16:35 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 > > The MAC address 00:1c:73:00:00::99 belongs to the gateway on my ISP's > side. I have no clue about the other 2 MAC addresses. Anyway, when > trying to investigate the matter, I found that link-local > addresses (i.e., fe80::/10) that are not part of fe80::/64, the only > block that is actually defined to be used per RFC 4291 Section 2.5.6, > always have the second octet pair as 0: > > router$ route -n get fe80:4::c6ca:2bff:fe5a:cf35%em0 -inet6 >route to: fe80::c6ca:2bff:fe5a:cf35%em0 > destination: fe80::c6ca:2bff:fe5a:cf35%em0 >mask: ::::::: > interface: em0 > if address: fe80::7ec2:55ff:fe62:31fb%em0 >priority: 3 () > flags: > use mtuexpire > 34 0 85085 > > Notice how "route to" does not have the same IP as the IP I passed to > route(8). Here is another example with a "random" link-local IP: > > router$ route -n get fe80:4:8349:adfe:1ca:2eff:95a:14%em0 -inet6 >route to: fe80:0:8349:adfe:1ca:2eff:95a:14%em0 > destination: fe80:: >mask: ffc0:: > gateway: ::1 > interface: lo0 > if address: ::1 >priority: 8 (static) > flags: > use mtuexpire > 27 32768 0 > > Is there something I am missing, or is this a bug? You are missing something. It is called the KAME hack or embedded scope. The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the scope_id. In some cases this embedded scope escapes in the addrs printed. Especially the "ndp info overwritten for" is leaking the scope_id (4) which is probably the interface index of your em0 interface. Welcome to IPv6, the world would be better without all the garbage. -- :wq Claudio
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
Huh? Please read what I said. I literally mentioned RFC 4291 Section 2.5.6. Additionally, fe80::/10 _is_ defined by RFC 4291 Section 2.4 as "Link-Local unicast" addresses. Section 2.5.6 does not redefine that but instead states that, at least as of now, only fe80::/64 is allowed to be used. The point of defining fe80::/10 as link-local despite only a portion of it being allowed to be used is to prevent other addresses in that block from being used for other purposes. I don't want this to devolve into a game of "Can you guess what RFC 4291 says?" though as I don't actually think it is relevant. route(8) and perhaps other areas of the OS/kernel appear to force the second octet pair to be 0 which may or may not be the cause of my "ndp info overwritten" messages. If you are trying to imply that all fe80::/10 addresses are interpreted as fe80::/64 addresses, then even that does not make sense since you can clearly see that it is only the _second_ octet pair that has 0 while the other octet pairs retain the values that were passed.
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On 2023-07-12 16:23, Zack Newman wrote: > Before I raise a bug report, I wanted to pass it by @misc in case I'm > confused. It appears there is an issue with link-local addresses at > least as far as route(8) is concerned. Since May 2, /var/log/messages > has been getting spammed with the following: > > router$ tail -6 /var/log/messages > Jul 12 03:02:47 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 > Jul 12 03:02:51 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 > Jul 12 04:57:30 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:8723 by c4:ca:2b:5a:87:23 on em0 > Jul 12 04:57:34 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:8723 by 00:1c:73:00:00:99 on em0 > Jul 12 06:16:31 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 > Jul 12 06:16:35 router /bsd: ndp info overwritten for > fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 > > The MAC address 00:1c:73:00:00::99 belongs to the gateway on my ISP's > side. I have no clue about the other 2 MAC addresses. Anyway, when > trying to investigate the matter, I found that link-local > addresses (i.e., fe80::/10) that are not part of fe80::/64, the only > block that is actually defined to be used per RFC 4291 Section 2.5.6, > always have the second octet pair as 0: > > router$ route -n get fe80:4::c6ca:2bff:fe5a:cf35%em0 -inet6 > route to: fe80::c6ca:2bff:fe5a:cf35%em0 > destination: fe80::c6ca:2bff:fe5a:cf35%em0 > mask: ::::::: > interface: em0 > if address: fe80::7ec2:55ff:fe62:31fb%em0 > priority: 3 () > flags: > use mtu expire > 34 0 85085 > > Notice how "route to" does not have the same IP as the IP I passed to > route(8). Here is another example with a "random" link-local IP: > > router$ route -n get fe80:4:8349:adfe:1ca:2eff:95a:14%em0 -inet6 > route to: fe80:0:8349:adfe:1ca:2eff:95a:14%em0 > destination: fe80:: > mask: ffc0:: > gateway: ::1 > interface: lo0 > if address: ::1 > priority: 8 (static) > flags: > use mtu expire > 27 32768 0 > > Is there something I am missing, or is this a bug? > I believe you are missing that Link-Local IPv6 addresses aren't the whole /10, they are only the /64. This is by design, since quite a few IPv6 functions depend on fe80::/64 being there. For further reference, see section 2.5.6 of RFC4291, the current version of the IPv6 Address Architecture. https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6 Kind Regards, -- Åke Nordin , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN
IPv6 link-local addresses outside of fe80::/64 are not handled correctly
Before I raise a bug report, I wanted to pass it by @misc in case I'm confused. It appears there is an issue with link-local addresses at least as far as route(8) is concerned. Since May 2, /var/log/messages has been getting spammed with the following: router$ tail -6 /var/log/messages Jul 12 03:02:47 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 Jul 12 03:02:51 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 Jul 12 04:57:30 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:8723 by c4:ca:2b:5a:87:23 on em0 Jul 12 04:57:34 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:8723 by 00:1c:73:00:00:99 on em0 Jul 12 06:16:31 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0 Jul 12 06:16:35 router /bsd: ndp info overwritten for fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0 The MAC address 00:1c:73:00:00::99 belongs to the gateway on my ISP's side. I have no clue about the other 2 MAC addresses. Anyway, when trying to investigate the matter, I found that link-local addresses (i.e., fe80::/10) that are not part of fe80::/64, the only block that is actually defined to be used per RFC 4291 Section 2.5.6, always have the second octet pair as 0: router$ route -n get fe80:4::c6ca:2bff:fe5a:cf35%em0 -inet6 route to: fe80::c6ca:2bff:fe5a:cf35%em0 destination: fe80::c6ca:2bff:fe5a:cf35%em0 mask: ::::::: interface: em0 if address: fe80::7ec2:55ff:fe62:31fb%em0 priority: 3 () flags: use mtuexpire 34 0 85085 Notice how "route to" does not have the same IP as the IP I passed to route(8). Here is another example with a "random" link-local IP: router$ route -n get fe80:4:8349:adfe:1ca:2eff:95a:14%em0 -inet6 route to: fe80:0:8349:adfe:1ca:2eff:95a:14%em0 destination: fe80:: mask: ffc0:: gateway: ::1 interface: lo0 if address: ::1 priority: 8 (static) flags: use mtuexpire 27 32768 0 Is there something I am missing, or is this a bug?
Re: iked server/client OBSD/OBSD
Am 09.07.23 11:38 schrieb Tobias Heider: > On Sat, Jul 08, 2023 at 11:08:31PM -0700, latin...@vcn.bc.ca wrote: > (...) > > ikev2 'roadwarrior' active esp \ > > from dynamic to any \ > > peer server_ip \ > > srcid roadwarrior \ > > dstid server_domain \ > > request address any \ > > iface lo1 > > > > Questions: > > should i add the \? > > Yes, because each policy is one line which isn't very convenient but it is > what ~~~ > it is for historical reasons. I just wanted to add one thing: To me this IS very convenient! If I want to disable/comment out this poloicy then I have to insert only one single '#' in front of 'ike'. If the policy were multiple lines then you would need multiple #'s - one on each row.
