OpenVPN routing

Bitrise Build Issue Report template

Description of the issue

We are trying to clone repository from VPN. For that we install and run openvpn. Connection is established and tunnel is open. After that we expect to access internal address but this fails. We expect the problem is with routing table but can’t access ‘route’ on the build machine.

Environment:

Android & Docker, on Ubuntu 18.04

Script version 1.1.5

Reproducibility

  • _Does a “Rebuild” help? NO
  • _Does a rebuild without caches help? NO
  • Does the issue happen sporadically, or every time? : Every time
  • Does upgrading the build Step to the latest version help? : NO
  • When did the issue start? : When we added vpn connection.

Local reproduction

Locally, we can open VPN and manipulate routing table.

Local reproduction: Linux / Android (docker based) stack builds

Can it be reproduced by running the build locally, after doing a new git clone of the repository into the /tmp directory and running the build from there with the Bitrise CLI ( https://www.bitrise.io/cli )? If no, can it be reproduced with Docker (using the same docker images / environment we use on bitrise.io)? Related guide: http://devcenter.bitrise.io/docker/run-your-build-locally-in-docker/ .

Build log

Thu Sep 27 09:23:30 2018 ROUTE_GATEWAY 10.240.0.1
Thu Sep 27 09:23:30 2018 TUN/TAP device tun0 opened
Thu Sep 27 09:23:30 2018 TUN/TAP TX queue length set to 100
Thu Sep 27 09:23:30 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Sep 27 09:23:30 2018 /sbin/ip link set dev tun0 up mtu 1500
Thu Sep 27 09:23:30 2018 /sbin/ip addr add dev tun0 local 10.0.201.158 peer 10.0.201.157
Thu Sep 27 09:23:30 2018 /sbin/ip route add 10.0.201.0/25 via 10.0.201.157
Thu Sep 27 09:23:30 2018 /sbin/ip route add 10.0.201.129/32 via 10.0.201.157
Thu Sep 27 09:23:30 2018 Initialization Sequence Completed
–2018-09-27 09:23:38-- http://gitlab..com/
Resolving gitlab.
.com (gitlab..com)… failed: Name or service not known.
wget: unable to resolve host address ‘gitlab.
.com’
Task was aborted

Hi @wwilczynski!

Could you send us an URL to this build so we can see it completely please?

Sure thing.

https://app.bitrise.io/build/ b8dc784f67d47667

Hi @wwilczynski,
Sorry for the really long delay on this! Could you try changing the
openvpn --config user.ovpn --askpass user.ovpn-pass &

line to

openvpn --config user.ovpn --askpass user.ovpn-pass &> $BITRISE_DEPLOY_DIR/logs.txt &
disown
1 Like

You need to install net-tools pacakge. E.g. by adding apt -y install net-tools to script at the beginning.

I changed this line in my script to:

I also installed

although I don’t need them.

So now the script is not hanging.

But still we can’t establish connection to repo.

Resolving gitlab..com (gitlab..com)... failed: Name or service not known.
wget: unable to resolve host address ‘gitlab..com’

From the openVPN logs I can see that

Thu Oct 11 07:47:34 2018 /sbin/ip link set dev tun0 up mtu 1500
Thu Oct 11 07:47:34 2018 /sbin/ip addr add dev tun0 local 10.0.201.158 peer 10.0.201.157
Thu Oct 11 07:47:34 2018 /sbin/ip route add 10.0.201.0/25 via 10.0.201.157
Thu Oct 11 07:47:34 2018 /sbin/ip route add 10.0.201.129/32 via 10.0.201.157
Thu Oct 11 07:47:34 2018 Initialization Sequence Completed

which means the tunnel is open.

I believe we need to use new network interface to establish the connection. Unfortunately, I cannot read/modify routing table.

route

gives no output.

Please, advice what to do next.

There are 2 dots.

1 Like

It’s private repository, one dot represent private repository name.
So it’s

gitlab.[something].com

Is that domain resolvable using public DNS servers? If not, are you sure that DNS server list is correct on build machine?

2 Likes

We use ip address instead of the hostname and now it’s working fine.

Thank you @koral and @tamasbazsonyi for help with this.

@wwilczynski perfect, I’m really glad to hear that, I took a note on this! @koral thank you very much for jumping in on this and helping out! :slightly_smiling_face:

This topic was automatically closed after 14 days. New replies are no longer allowed.