[SCION] VPN configuration failure

[Matthew McCormack]

All of the issues go away when configured to use direct connect to the AP
(without the VPN). After re-running scionlab-config, the border-router
service is running, and SCMP echo succeeds to SCION APs.

I'm confused why I had VPN issues, as I installed openVPN from the debian
packages and ran scionlab-config then started the services (openvpn at client,
scionlab.target).

As a note, when reverting from the direct connect back to the VPN
configuration for the AS, the issues do not return. The border-router
service runs and the webapp does not identify the VPN as being
misconfigured.

On Wed, Dec 11, 2019 at 2:52 PM Kowalski Mateusz <
mateusz.kowalski at inf.ethz.ch> wrote:

> Hi guys,
>
> Please do one if the following
>
> 1) test whether your VPN connection to the AP is established correctly;
> without it the border router will not start
> 2) configure your user AS properly i.e. without using a VPN; if the
> problem persists with the direct connection to the AP, the problem will be
> either AP’s configuration or the SCION itself
>
> Statistically speaking I bet you don’t have a working VPN, but this
> statement is not backed by any logs
>
> Cheers,
> Mateusz
> ------------------------------
> *From:* SCION <scion-bounces at lists.inf.ethz.ch> on behalf of Matthew
> McCormack <mmccorm1 at andrew.cmu.edu>
> *Sent:* 11 December 2019 19:31:09
> *To:* scion at lists.inf.ethz.ch
> *Subject:* Re: [SCION] VPN configuration failure
>
> As a follow-up, while debugging with Michael a key item we noted was that
> the border-router service is not running (also not listed when running
> systemctl list-dependencies):
>
> $ sudo systemctl list-dependencies scionlab.target
> scionlab.target
> ● ├─scion-beacon-server at 17-ffaa_1_d13-1.service
> ● ├─scion-beacon-server at 17-ffaa_1_d13-1.service
> ● ├─scion-certificate-server at 17-ffaa_1_d13-1.service
> ● ├─scion-certificate-server at 17-ffaa_1_d13-1.service
> ● ├─scion-daemon at 17-ffaa_1_d13.service
> ● ├─scion-daemon at 17-ffaa_1_d13.service
> ● ├─scion-dispatcher.service
> ● ├─scion-dispatcher.service
> ● ├─scion-path-server at 17-ffaa_1_d13-1.service
> ● ├─scion-path-server at 17-ffaa_1_d13-1.service
> ● └─scion-webapp.service
>
> When I attempt to manually start the border-router, it fails:
>
> $ sudo systemctl status scion-border-router at 17-ffaa_1_d13-1.service
>
> *●* scion-border-router at 17-ffaa_1_d13-1.service - SCION Border Router
>
>    Loaded: loaded (/lib/systemd/system/scion-border-router at .service;
> disabled; vendor preset: enabled)
>
>    Active: *failed* (Result: start-limit-hit) since Wed 2019-12-11
> 12:23:43 CST; 46s ago
>
>      Docs: https://www.scionlab.org
>
>   Process: 28270 ExecStart=/usr/bin/scion-systemd-wrapper
> /usr/bin/border /etc/scion/gen/ISD-isd-/AS-as-/br%i/br.toml %i
> *(code=exited, status=1/*
>
>  Main PID: 28270 (code=exited, status=1/FAILURE)
>
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *scion-border-router at 17-ffaa_1_d13-1.service: Unit entered failed
> state.*
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *scion-border-router at 17-ffaa_1_d13-1.service: Failed with result
> 'exit-code'*
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> scion-border-router at 17-ffaa_1_d13-1.service: Service hold-off time
> over, scheduling restart
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> Stopped SCION Border Router.
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *scion-border-router at 17-ffaa_1_d13-1.service: Start request repeated
> too quickly*
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *Failed to start SCION Border Router.*
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *scion-border-router at 17-ffaa_1_d13-1.service: Unit entered failed
> state.*
>
> Dec 11 12:23:43 dataplane.scion.psi-pg0.wisc.cloudlab.us systemd[1]:
> *scion-border-router at 17-ffaa_1_d13-1.service: Failed with result
> 'start-limit-hit'.*
>
>
> Thanks for the help!
>
> -Matt
>
>
> On Wed, Dec 11, 2019 at 12:07 PM Matthew McCormack <
> mmccorm1 at andrew.cmu.edu>
> wrote:
>
> > Hello,
> >
> > In attempting to setup an AS (attached to the ETHZ-AP), I am experiencing
> > an issue (at least one reported by the webapp) with the VPN. I built the
> AS
> > from debian packages. I can ping a SCION AP, but when I attempt to send
> an
> > SCMP echo message, I receive the following error message: CRIT:
> > SCIOND unable to retrieve paths: SCIOND experienced an internal error
> >
> > The webapp reports that the VPN configuration test fails with the
> > following message:
> > Traceback (most recent call last):
> > File \"\", line 3, in
> > StopIteration
> >
> > As a side note, the webapp reports that the SCMP test passes, but does
> not
> > report the host's public IP address but the address of a different NIC on
> > the machine. When I attempt to manually send an SCMP echo, I receive the
> > error message above about SCIONd not being able to retrieve paths.
> >
> > I am not receiving any SCION beacon messages. The only items in the log
> > are for starting periodic tasks.
> >
> > --
> > Thank you for your time and consideration.
> >
> > Very Respectfully,
> > Matt McCormack
> >
>
>
> --
> Thank you for your time and consideration.
>
> Very Respectfully,
> Matt McCormack
> _______________________________________________
> SCION mailing list
> SCION at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/scion
>


-- 
Thank you for your time and consideration.

Very Respectfully,
Matt McCormack