Manageiq not access to Hawkular in Centos 7 VMWare - vmware-workstation

My development environment is CentOS 7 in vmware workstation 11 and manageiq docker container (manageiq/manageiq:euwe-2) on eclipse docker perspective. The manageiq appplication (https://127.0.0.1:8443) is executed well. But connecting hawkular is failed. Below is my hawkular execution command
<HAWKULAR_HOME>./standalone.sh -Dhawkular.rest.user=jhwang –Dhawkular.rest.password=password -Dhawkular.agent.enabled=true -b 192.168.200.51
In manageiq web console I type in the IP address on hawkular hostname but connection failes. Here is the image of manageiq:
Outside of VMWare workstation, the above process works well. ManageIQ is making the connection with the Hawkular with Hawkular binding IP address. But in vmware, no access. I am afraid I am using wrong Hawkular binding address. I attach the output of ifconfig command.
$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
inet6 fe80::42:8fff:fe28:6f2d prefixlen 64 scopeid 0x20<link>
ether 02:42:8f:28:6f:2d txqueuelen 0 (Ethernet)
RX packets 1283 bytes 342465 (334.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1344 bytes 157135 (153.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.200.51 netmask 255.255.255.0 broadcast 192.168.200.255
inet6 fe80::c494:6514:b641:e046 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:57:00:09 txqueuelen 1000 (Ethernet)
RX packets 10875 bytes 7648436 (7.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7465 bytes 1019458 (995.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 48647 bytes 14786880 (14.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 48647 bytes 14786880 (14.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethcf88378: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::c000:d9ff:fe82:e915 prefixlen 64 scopeid 0x20<link>
ether c2:00:d9:82:e9:15 txqueuelen 0 (Ethernet)
RX packets 1283 bytes 360427 (351.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1352 bytes 157783 (154.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:ce:2f:27 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
And these are logs
[Sun Apr 23 01:08:01.546217 2017] [proxy_http:error] [pid 862] [client 172.17.0.1:58384] AH01114: HTTP: failed to make connection to backend: 0.0.0.0, referer: https://127.0.0.1:8443/
[Sun Apr 23 01:08:01.546274 2017] [proxy:error] [pid 862] (111)Connection refused: AH00957: HTTP: attempt to connect to 0.0.0.0:3008 (0.0.0.0) failed
[Sun Apr 23 01:08:01.546280 2017] [proxy:error] [pid 862] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:01.546281 2017] [proxy_http:error] [pid 862] [client 172.17.0.1:58384] AH01114: HTTP: failed to make connection to backend: 0.0.0.0, referer: https://127.0.0.1:8443/
[Sun Apr 23 01:08:01.546346 2017] [proxy:error] [pid 862] (111)Connection refused: AH00957: HTTP: attempt to connect to 0.0.0.0:3009 (0.0.0.0) failed
[Sun Apr 23 01:08:01.546352 2017] [proxy:error] [pid 862] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:01.546353 2017] [proxy_http:error] [pid 862] [client 172.17.0.1:58384] AH01114: HTTP: failed to make connection to backend: 0.0.0.0, referer: https://127.0.0.1:8443/
[Sun Apr 23 01:08:17.874238 2017] [proxy:error] [pid 864] (111)Connection refused: AH00957: WS: attempt to connect to 0.0.0.0:5001 (0.0.0.0) failed
[Sun Apr 23 01:08:17.875769 2017] [proxy:error] [pid 864] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:17.876936 2017] [proxy_wstunnel:error] [pid 864] [client 172.17.0.1:58492] AH02452: failed to make connection to backend: 0.0.0.0
[Sun Apr 23 01:08:17.877157 2017] [proxy:error] [pid 864] (111)Connection refused: AH00957: WS: attempt to connect to 0.0.0.0:5002 (0.0.0.0) failed
[Sun Apr 23 01:08:17.877170 2017] [proxy:error] [pid 864] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:17.877173 2017] [proxy_wstunnel:error] [pid 864] [client 172.17.0.1:58492] AH02452: failed to make connection to backend: 0.0.0.0
[Sun Apr 23 01:08:17.877542 2017] [proxy:error] [pid 864] (111)Connection refused: AH00957: WS: attempt to connect to 0.0.0.0:5003 (0.0.0.0) failed
[Sun Apr 23 01:08:17.877552 2017] [proxy:error] [pid 864] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:17.877554 2017] [proxy_wstunnel:error] [pid 864] [client 172.17.0.1:58492] AH02452: failed to make connection to backend: 0.0.0.0
[Sun Apr 23 01:08:17.877717 2017] [proxy:error] [pid 864] (111)Connection refused: AH00957: WS: attempt to connect to 0.0.0.0:5004 (0.0.0.0) failed
[Sun Apr 23 01:08:17.877724 2017] [proxy:error] [pid 864] AH00959: ap_proxy_connect_backend disabling worker for (0.0.0.0) for 60s
[Sun Apr 23 01:08:17.877726 2017] [proxy_wstunnel:error] [pid 864] [client 172.17.0.1:58492] AH02452: failed to make connection to backend: 0.0.0.0
[Sun Apr 23 01:08:17.877799 2017] [proxy:error] [pid 864] (111)Connection refused: AH00957: WS: attempt to connect to 0.0.0.0:5005 (0.0.0.0) failed


This disconnection is due to "iptables that was blocking the loopback port".
So the one command line solved my issue.
iptables -I INPUT 1 -i docker0 -j ACCEPT

Related

How to apply multi VFs with virtio-net vDPA on host?

Recently, I was developing vDPA drivers for our NIC. When testing virtio-net vDPA with multi VFs, I found that kernel vDPA framework allocated same DMA addresses for multi VFs, then different VF operate the same DMA address, such as updating the used index, cause kernel virtqueues works abnormally.
The steps are as follows:
enable the NIC sriov, create 4 VFs, we can see that 4 vdpa management devices are create successful.
*[root#localhost ~]# echo 4 > /sys/class/net/enp1s0np0/device/sriov_numvfs
[root#localhost ~]# vdpa mgmtdev show
pci/0000:01:08.0:
supported_classes net
pci/0000:01:08.1:
supported_classes net
pci/0000:01:08.2:
supported_classes net
pci/0000:01:08.3:
supported_classes net*
add vdpa device and enable virtio vdpa module. create 4 vdpa device and the driver are binded successful.
*[root#localhost ~]# vdpa dev add mgmtdev pci/0000:01:08.0 name vdpa0
[root#localhost ~]# vdpa dev add mgmtdev pci/0000:01:08.1 name vdpa1
[root#localhost ~]# vdpa dev add mgmtdev pci/0000:01:08.2 name vdpa2
[root#localhost ~]# vdpa dev add mgmtdev pci/0000:01:08.3 name vdpa3
[root#localhost ~]# modprobe virtio_vdpa
[root#localhost ~]# ls -l /sys/bus/vdpa/drivers/virtio_vdpa/
total 0
--w-------. 1 root root 4096 Nov 21 16:55 bind
lrwxrwxrwx. 1 root root 0 Nov 21 16:55 module -> ../../../../module/virtio_vdpa
--w-------. 1 root root 4096 Nov 21 16:55 uevent
--w-------. 1 root root 4096 Nov 21 16:55 unbind
lrwxrwxrwx. 1 root root 0 Nov 21 16:55 vdpa0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:08.0/vdpa0
lrwxrwxrwx. 1 root root 0 Nov 21 16:55 vdpa1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:08.1/vdpa1
lrwxrwxrwx. 1 root root 0 Nov 21 16:55 vdpa2 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:08.2/vdpa2
lrwxrwxrwx. 1 root root 0 Nov 21 16:55 vdpa3 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:08.3/vdpa3*
check the kernel messages output, we can see the virtio-net device and dma addresses.
*[Mon Nov 21 16:55:42 2022] virtio_net virtio0: devname virtio0 name input.0 index 0 dmaaddr ffffc000
[Mon Nov 21 16:55:42 2022] virtio_net virtio0: devname virtio0 name output.0 index 1 dmaaddr ffff8000
[Mon Nov 21 16:55:42 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[Mon Nov 21 16:55:42 2022] virtio_net virtio1: devname virtio1 name input.0 index 0 dmaaddr ffffc000
[Mon Nov 21 16:55:42 2022] virtio_net virtio1: devname virtio1 name output.0 index 1 dmaaddr ffff8000
[Mon Nov 21 16:55:42 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[Mon Nov 21 16:55:42 2022] virtio_net virtio2: devname virtio2 name input.0 index 0 dmaaddr ffffc000
[Mon Nov 21 16:55:42 2022] virtio_net virtio2: devname virtio2 name output.0 index 1 dmaaddr ffff8000
[Mon Nov 21 16:55:42 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[Mon Nov 21 16:55:42 2022] virtio_net virtio0 enp1s0v0: renamed from eth5
[Mon Nov 21 16:55:42 2022] virtio_net virtio3: devname virtio3 name input.0 index 0 dmaaddr ffffc000
[Mon Nov 21 16:55:42 2022] virtio_net virtio3: devname virtio3 name output.0 index 1 dmaaddr ffff8000
[Mon Nov 21 16:55:42 2022] virtio_net virtio1 enp1s0v1: renamed from eth6
[Mon Nov 21 16:55:42 2022] virtio_net virtio2 enp1s0v2: renamed from eth7
[Mon Nov 21 16:55:42 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready
[Mon Nov 21 16:55:42 2022] virtio_net virtio3 enp1s0v3: renamed from eth5*
It seems that kernel vDPA framework assigns the same virtqueue dma address to four different vf.
This application scenario refers to the vDPA description of Red Hat: https://www.redhat.com/en/blog/vdpa-kernel-framework-part-3-usage-vms-and-containers
My kernel version is 5.15.15, kernel vDPA options are all enabled when compile the kernel.
[root#localhost linux-5.15.15]# cat .config | grep VDPA
`CONFIG_VIRTIO_VDPA=m
CONFIG_VDPA=y
CONFIG_VDPA_SIM=m
CONFIG_VDPA_SIM_NET=m
CONFIG_VDPA_SIM_BLOCK=m
#CONFIG_VDPA_USER is not set
CONFIG_MLX5_VDPA=y
CONFIG_MLX5_VDPA_NET=m
CONFIG_VP_VDPA=m
CONFIG_VHOST_VDPA=m`
[root#localhost linux-5.15.15]#
So, is there anything i missed or misunderstood about the kernel vDPA framework, if someone can give some advice, that will be great help. thanks a lot.
I've tested with vhost-vdpa, start VMs with QEMU, and multi VFs works well.

I’ve investigated the virtio specification, and found that the virtio 1.1 specification has updated and add a new feature bit VIRTIO_F_SR_IOV. I guess that there will be some adaptation in the kernel vDPA framework to support multi vf. But currently I haven't seen the implementation in the 5.19 kernel yet. However, this confirms that the kernel framework is not yet supported.
The requirement for VIRTIO_F_SR_IOV as follows( see virtio 1.1 specification chapter 6.1/6.2):
If VIRTIO_F_SR_IOV has been negotiated, a driver MAY enable virtual functions through the device's PCI SR-IOV capability structure. A driver MUST NOT negotiate VIRTIO_F_SR_IOV if the device does not have a PCI SR-IOV capability structure or is not a PCI device. A driver MUST negotiate VIRTIO_F_SR_IOV and complete the feature negotiation (including checking the FEATURES_OK device status bit) before enabling virtual functions through the device's PCI SR-IOV capability structure. After once successfully negotiating VIRTIO_F_SR_IOV, the driver MAY enable virtual functions through the device's PCI SR-IOV capability structure even if the device or the system has been fully or partially reset, and even without re-negotiating VIRTIO_F_SR_IOV after the reset.
A device SHOULD offer VIRTIO_F_SR_IOV if it is a PCI device and presents a PCI SR-IOV capability structure, otherwise it MUST NOT offer VIRTIO_F_SR_IOV
see changes:
https://www.oasis-open.org/committees/ballot.php?id=3218
https://github.com/oasis-tcs/virtio-spec/issues/11
we are looking forward the future kernel version will support this feature.

PiVpn does not route traffic to LAN

I am using PiVPN on my Raspberry Pi.
It connects correctly but it does not route traffic to my LAN.
My topology is the following:
LAN: 192.168.1.0/24
VPN network: 10.192.125.0/24
Laptop connected to mobile (192.168.43.1) via tethering
Laptop attempting to connect to VPN
server.conf:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
key /etc/openvpn/easy-rsa/pki/private/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.192.125.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
# push "route 192.168.1.0 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 4
mssfix 1350
This is my OVPN client conf:
client
dev tun
proto udp
remote <my_host> 1194
resolv-retry infinite
nobind
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
<tls-auth>
...
</tls-auth>
After connecting, I have the following routing table on the client:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.192.125.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.43.1 0.0.0.0 UG 600 0 0 wlp1s0
10.192.125.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
<PUBLIC_IP> 192.168.43.1 255.255.255.255 UGH 0 0 0 wlp1s0
128.0.0.0 10.192.125.1 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker_gwbridge
192.168.43.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp1s0
Here I also tried explicitly pushing a route to 192.168.1.0, with no noticeable change.
On the OpenVPN server I have the following IPTABLES configuration:
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 10.192.125.0/24 ctstate RELATED,ESTABLISHED /* openvpn-forward-rule */
ACCEPT all -- 10.192.125.0/24 anywhere /* openvpn-forward-rule */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE all -- 10.192.125.0/24 anywhere /* openvpn-nat-rule */
MASQUERADE all -- anywhere anywhere ADDRTYPE match src-type LOCAL
MASQUERADE all -- 172.19.0.0/16 anywhere
I enabled forwarding on the kernel by adding net.ipv4.ip_forward=1 on sysctl.conf.
When tracerouting a host from the LAN, I see it uses the OpenVPN server as the gateway.
# traceroute 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 hops max, 60 byte packets
1 10.192.125.1 (10.192.125.1) 163.487 ms 163.746 ms 163.754 ms
2 * * *
...
These are the logs on the client when connecting:
Mon Nov 7 08:19:19 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Mon Nov 7 08:19:19 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Enter Private Key Password: ***********************
Mon Nov 7 08:19:23 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 7 08:19:23 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 7 08:19:24 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:24 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Nov 7 08:19:24 2022 UDP link local: (not bound)
Mon Nov 7 08:19:24 2022 UDP link remote: [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:24 2022 TLS: Initial packet from [AF_INET]<PUBLIC_IP>:1194, sid=68ddb126 123bae54
Mon Nov 7 08:19:24 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Mon Nov 7 08:19:24 2022 VERIFY KU OK
Mon Nov 7 08:19:24 2022 Validating certificate extended key usage
Mon Nov 7 08:19:24 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Nov 7 08:19:24 2022 VERIFY EKU OK
Mon Nov 7 08:19:24 2022 VERIFY X509NAME OK: CN=raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5
Mon Nov 7 08:19:24 2022 VERIFY OK: depth=0, CN=raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5
Mon Nov 7 08:19:24 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Mon Nov 7 08:19:24 2022 [raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5] Peer Connection Initiated with [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:25 2022 SENT CONTROL [raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5]: 'PUSH_REQUEST' (status=1)
Mon Nov 7 08:19:25 2022 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,redirect-gateway def1,route 192.168.1.0 255.255.255.0,route-gateway 10.192.125.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.192.125.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Mon Nov 7 08:19:25 2022 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: block-outside-dns (2.4.7)
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: route options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: route-related options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: peer-id set
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: adjusting link_mtu to 1624
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: data channel crypto options modified
Mon Nov 7 08:19:25 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Nov 7 08:19:25 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 7 08:19:25 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 7 08:19:25 2022 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlp1s0 HWADDR=a4:97:b1:8e:37:af
Mon Nov 7 08:19:25 2022 TUN/TAP device tun0 opened
Mon Nov 7 08:19:25 2022 TUN/TAP TX queue length set to 100
Mon Nov 7 08:19:25 2022 /sbin/ip link set dev tun0 up mtu 1500
Mon Nov 7 08:19:25 2022 /sbin/ip addr add dev tun0 10.192.125.3/24 broadcast 10.192.125.255
Mon Nov 7 08:19:25 2022 /sbin/ip route add <PUBLIC_IP>/32 via 192.168.1.254
Mon Nov 7 08:19:25 2022 /sbin/ip route add 0.0.0.0/1 via 10.192.125.1
Mon Nov 7 08:19:25 2022 /sbin/ip route add 128.0.0.0/1 via 10.192.125.1
Mon Nov 7 08:19:25 2022 /sbin/ip route add 192.168.1.0/24 via 10.192.125.1
Mon Nov 7 08:19:25 2022 Initialization Sequence Completed
Finally, PiVPN seems to be happy about the configuration:
root#raspberrypi:~# cat /tmp/debug.log
:::: PiVPN debug ::::
=============================================
:::: Latest commit ::::
Branch: master
Commit: f8cb945af15a1ca0cf063475c6e1557c6e8da06c
Author: 4s3ti
Date: Fri Jun 10 16:10:57 2022 +0200
Summary: Merge branch 'test'
=============================================
:::: Installation settings ::::
PLAT=Debian
OSCN=bullseye
USING_UFW=0
pivpnforceipv6route=1
IPv4dev=wlan1
dhcpReserv=1
IPv4addr=192.168.1.223/24
IPv4gw=192.168.1.254
install_user=pi
install_home=/home/pi
VPN=openvpn
pivpnPROTO=udp
pivpnPORT=1194
pivpnDNS1=1.1.1.1
pivpnDNS2=1.0.0.1
pivpnSEARCHDOMAIN=
pivpnHOST=REDACTED
TWO_POINT_FOUR=0
pivpnENCRYPT=2048
USE_PREDEFINED_DH_PARAM=1
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=1
INPUT_CHAIN_EDITEDv6=
FORWARD_CHAIN_EDITEDv6=
pivpnDEV=tun0
pivpnNET=10.192.125.0
subnetClass=24
pivpnenableipv6=0
ALLOWED_IPS=""
UNATTUPG=1
INSTALLED_PACKAGES=(dnsutils grepcidr bsdmainutils iptables-persistent openvpn expect unattended-upgrades)
HELP_SHOWN=1
=============================================
:::: Server configuration shown below ::::
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
key /etc/openvpn/easy-rsa/pki/private/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.192.125.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
# push "route 192.168.1.0 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 4
mssfix 1350
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io
=============================================
:::: Client template file shown below ::::
client
dev tun
proto udp
remote REDACTED 1194
resolv-retry infinite
nobind
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
=============================================
:::: Recursive list of files in ::::
::: /etc/openvpn/easy-rsa/pki shows below :::
/etc/openvpn/easy-rsa/pki/:
Default.txt
MirkoSmartphone.ovpn
Motog8Mirko3.ovpn
ca.crt
crl.pem
dh2048.pem
index.txt
index.txt.attr
index.txt.attr.old
index.txt.old
issued
openssl-easyrsa.cnf
private
revoked
safessl-easyrsa.cnf
serial
serial.old
ta.key
vars
vars.example
/etc/openvpn/easy-rsa/pki/issued:
MirkoSmartphone.crt
Motog8Mirko3.crt
motog8mirko.crt
raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
/etc/openvpn/easy-rsa/pki/private:
MirkoSmartphone.key
Motog8Mirko3.key
ca.key
motog8mirko.key
raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
/etc/openvpn/easy-rsa/pki/revoked:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/revoked/private_by_serial:
/etc/openvpn/easy-rsa/pki/revoked/reqs_by_serial:
=============================================
:::: Self check ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] Iptables FORWARD rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 1194/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: https://docs.pivpn.io/faq
=============================================
:::: Snippet of the server log ::::
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 peer info: IV_SSO=webauth,openurl
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 [Motog8Mirko3] Peer Connection Initiated with [AF_INET]REDACTED:33665
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI_sva: pool returned IPv4=10.192.125.2, IPv6=(Not enabled)
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/Motog8Mirko3
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: Learn: 10.192.125.3 -> Motog8Mirko3/REDACTED:33665
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: primary virtual IP for Motog8Mirko3/REDACTED:33665: 10.192.125.3
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Data Channel: using negotiated cipher 'AES-256-GCM'
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Data Channel MTU parms [ L:1549 D:1350 EF:49 EB:406 ET:0 EL:3 ]
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 SENT CONTROL [Motog8Mirko3]: 'PUSH_REPLY,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,redirect-gateway def1,route-gateway 10.192.125.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.192.125.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 PUSH: Received control message: 'PUSH_REQUEST'
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_0] 0:3 0:2 t=1667807356[0] r=[0,64,15,1,1] sl=[61,3,64,528]
Nov 7 08:49:17 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:17 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:19 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:19 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:23 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:23 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
=============================================
:::: Debug complete ::::

Is there a way to use ident authentication with pghero or other workaround?

Installed pghero according to the github docs (on CentOS 7), but seeing nothing in web browser (no connection error displayed, but browser is totally blank) and when starting service curl giving response. Looking at the logs I see...
[root#airflowetl ~]# pghero logs
==> /var/log/pghero/production.log <==
Started GET "/" for 127.0.0.1 at 2020-01-28 16:21:47 -1000
Processing by PgHero::HomeController#index as */*
Completed 500 Internal Server Error in 55ms
PG::ConnectionBad (FATAL: password authentication failed for user "airflow"):
...
...
...
Started GET "/" for 127.0.0.1 at 2020-01-28 23:51:28 -1000
Processing by PgHero::HomeController#index as */*
Completed 500 Internal Server Error in 11ms
PG::ConnectionBad (FATAL: Ident authentication failed for user "airflow"):
...
...
...
Jan 28 22:59:10 airflowetl.co.local systemd[1]: pghero-web-1.service holdoff time over, scheduling restart.
Jan 28 22:59:10 airflowetl.co.local systemd[1]: Stopped pghero-web-1.service.
Jan 28 22:59:10 airflowetl.co.local systemd[1]: start request repeated too quickly for pghero-web-1.service
Jan 28 22:59:10 airflowetl.co.local systemd[1]: Failed to start pghero-web-1.service.
Jan 28 22:59:10 airflowetl.co.local systemd[1]: Unit pghero-web-1.service entered failed state.
Jan 28 22:59:10 airflowetl.co.local systemd[1]: pghero-web-1.service failed.
Jan 28 23:09:36 airflowetl.co.local systemd[1]: Stopping pghero-web.service...
Jan 28 23:09:36 airflowetl.co.local systemd[1]: Stopped pghero-web.service.
Jan 28 23:09:36 airflowetl.co.local systemd[1]: Started pghero-web.service.
Jan 28 23:09:36 airflowetl.co.local systemd[1]: Started pghero-web-1.service.
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] Puma starting in cluster mode...
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Version 4.3.0 (ruby 2.6.3-p62), codename: Mysterious Trave
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Min threads: 1, max threads: 16
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Environment: production
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Process workers: 3
Jan 28 23:09:37 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Preloading application
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] * Listening on tcp://0.0.0.0:3001
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] ! WARNING: Detected 1 Thread(s) started in app boot:
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] ! #<Thread:0x0000561740ea27e0#/opt/pghero/vendor/bundle/ruby
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] Use Ctrl-C to stop
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] - Worker 0 (pid: 12213) booted, phase: 0
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] - Worker 1 (pid: 12215) booted, phase: 0
Jan 28 23:09:38 airflowetl.co.local pghero-web-1.service[12134]: [12134] - Worker 2 (pid: 12219) booted, phase: 0
...
and can see the
500 Internal Server Error in 55ms
error. Checking the service status, seeing...
[root#airflowetl ~]# service pghero status
Redirecting to /bin/systemctl status pghero.service
● pghero.service
Loaded: loaded (/etc/systemd/system/pghero.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-01-28 23:09:36 HST; 4s ago
Main PID: 12132 (sleep)
CGroup: /system.slice/pghero.service
└─12132 /bin/sleep infinity
Jan 28 23:09:36 airflowetl.co.local systemd[1]: Started pghero.service.
[root#airflowetl ~]# netstat -tulnp | grep 3001
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN 12134/puma 4.3.0 (t
[root#airflowetl ~]# curl -v http://localhost:3001/
* About to connect() to localhost port 3001 (#0)
* Trying ::1...
* Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3001 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:3001
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Content-Type: text/html; charset=UTF-8
< X-Request-Id: 2bad5f50-438e-4cb3-8e79-41c84eb75c2c
< X-Runtime: 0.017069
< Content-Length: 0
<
* Connection #0 to host localhost left intact
No experience with postgresql or db admin stuff, but appears that the error is due to the fact that I use ident authentication (and appears pghero wants to use a password):
[root#airflowetl ~]# cat /var/lib/pgsql/data/pg_hba.conf
# PostgreSQL Client Authentication Configuration File
# ===================================================
...
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
#host all all 127.0.0.1/32 ident
#host all all 0.0.0.0/0 trust
host all all 0.0.0.0/0 md5
#host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 ident
#host replication postgres ::1/128 ident
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
#listen_addresses = 'localhost' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
listen_addresses = '*' # for apache-airflow connection
I did this following an article of setting up psql as backend for airflow orchestration tool.
Have tried using multiple urls
sudo pghero config:set DATABASE_URL=postgresql://airflow:xxxx#localhost:5432/airflow
sudo pghero config:set DATABASE_URL=postgresql+psycopg2://airflow:xxxx#localhost:5432/airflow
but same results.
Not sure how to move forward at this point. Anyone with more experience with pghero or postgresql know what could be done here?

No experience with postgresql or db admin stuff, but appears that the error is due to the fact that I use ident authentication (and appears pghero wants to use a password)
It isn't about what pghero wants. It is PostgreSQL which is demanding password authentication.
host all all 0.0.0.0/0 md5
host all all ::1/128 ident
You are using md5 (i.e. password) on all IPv4 connections (including "localhost"), and using ident on only the IPv6 connection from ::1, which is the IPv6 way of spelling "localhost". pghero is coming in over IPv4, not IPv6, so it is getting commanded to use a password.
You can change the "md5" to "ident" for the 0.0.0.0/0 line (but you probably shouldn't as "ident" is not very secure from outside hosts), or add a line before that one to indicate 127.0.0.1/32 specifically should use ident. Or change your pghero config to try to connect over IPv6 rather than IPv4.
Your new log file entry shows that it is trying ident and failing at that too. I don't understand why you are getting both, but they are 7 hours apart so maybe you had changed pg_hba.conf in between. PostgreSQL will create a more complete report and put it in the PostgreSQL server's log file about why the ident authentication failed. (It doesn't sent to the complete report to the unauthenticated client, because that would reveal sensitive information). Find the PostgreSQL server's log file.

send mail as non root user

I am trying to send a mail with a non root user (also by tuleap application) but i have some trouble.
when we use a root user with command
echo “TR : This is a test of sending mail” | mail -s Test <mail>
it return this log and my email is sent
Mar 10 16:59:09 localhost sendmail[11969]: t2AGx9Up011969: from=root, size=258, class=0, nrcpts=1, msgid=<201503101659.t2AGx9Up011969#localhost.localdomain>, relay=root#localhost
Mar 10 16:59:09 localhost sendmail[11970]: t2AGx9Js011970: from=<root#localhost.localdomain>, size=521, class=0, nrcpts=1, msgid=<201503101659.t2AGx9Up011969#localhost.localdomain>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Mar 10 16:59:09 localhost sendmail[11969]: t2AGx9Up011969: to=<my mail>, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30258, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (t2AGx9Js011970 Message accepted for delivery)
Mar 10 16:59:12 localhost sendmail[11972]: STARTTLS=client, relay=<my SMTP server>, version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 10 16:59:15 localhost sendmail[11972]: t2AGx9Js011970: to=<my mail>, ctladdr=<root#localhost.localdomain> (0/0), delay=00:00:06, xdelay=00:00:06, mailer=relay, pri=120521, relay=<my SMTP server> [IP], dsn=2.0.0, stat=Sent (OK id=1YVNUv-002ihW-JJ)
but when we use an other use (like codendiadm as used by tuleap) with the same command, it return this log without sending mail
Mar 10 16:59:53 localhost sendmail[12024]: t2AGxrhg012024: from=codendiadm, size=258, class=0, nrcpts=1, msgid=<201503101659.t2AGxrhg012024#localhost.localdomain>, relay=codendiadm#localhost
Mar 10 16:59:53 localhost sendmail[12025]: t2AGxr16012025: from=<codendiadm#localhost.localdomain>, size=556, class=0, nrcpts=1, msgid=<201503101659.t2AGxrhg012024#localhost.localdomain>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Mar 10 16:59:53 localhost sendmail[12024]: t2AGxrhg012024: to=<my mail>, ctladdr=codendiadm (495/492), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30258, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (t2AGxr16012025 Message accepted for delivery)
Mar 10 16:59:57 localhost sendmail[12027]: STARTTLS=client, relay=<my SMTP server>, version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 10 17:00:00 localhost sendmail[12027]: t2AGxr16012025: to=<my mail>, ctladdr=<codendiadm#localhost.localdomain> (495/492), delay=00:00:07, xdelay=00:00:07, mailer=relay, pri=120556, relay=<my SMTP server> [IP], dsn=5.1.1, stat=User unknown
Mar 10 17:00:00 localhost sendmail[12027]: t2AGxr16012025: t2AH0016012027: DSN: User unknown

Try to remove sendmail and install postfix instead. And tell me if it works better this way. You'll find how to do it here.

openVPN: how to establish a connection between clients? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
This weekend I was working on a VPN connection between my two raspberry Pi (B and the new model 2). I chose openVPN for it. Both running Raspbian Wheezy.
So my setup is as follows:
|B| is at home connected to the internet (DSL, static IP).
The other Pi |2| I'm carrying with me. It's connected to the internet via a UMTS Router. That's works unexpectedly well :)
At home on the |B| I got a server running and the |2| logs into it without any problems.
My question for you guys is:
How do I connect from my local network (same as PI |B|), say from my iPhone, to the |2| which has already a connection opened to the |B|?
I configured my server like this:
dev tun
proto udp
port 34345
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway def1 bypass-dhcp"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo
duplicate-cn
keepalive 10 120
and that's my client config:
dev tun
client
proto udp
remote {myIP} 34345 #same port as on the server
resolv-retry infinite
nobind
persist-key
persist-tun
ca /home/pi/vpn/ca.crt
cert /home/pi/vpn/raspi.crt
key /home/pi/vpn/raspi.key
comp-lzo
verb 3
As I said, the connection works well and if I issue "curl www.echoip.net/plain" from within the console on the new raspberry I get my static IP address back. So I guess in general it works.
I already tried to access 10.8.0.* but this didn't work and I can't think of why?
Any ideas?
Thanks in advance,
Felix
EDITED AGAIN:
the server log says after successful authentification the following when the raspi connects:
Tue Mar 3 18:59:00 2015 2.240.44.246:26966 [raspi] Peer Connection Initiated with [AF_INET]2.240.44.246:26966
Tue Mar 3 18:59:00 2015 raspi/2.240.44.246:26966 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=e8b6:d1be:808e:f8b6:34bb:fdb6:4405:79b8
Tue Mar 3 18:59:00 2015 raspi/2.240.44.246:26966 MULTI: Learn: 10.8.0.6 -> raspi/2.240.44.246:26966
Tue Mar 3 18:59:00 2015 raspi/2.240.44.246:26966 MULTI: primary virtual IP for raspi/2.240.44.246:26966: 10.8.0.6
Tue Mar 3 18:59:02 2015 raspi/2.240.44.246:26966 PUSH: Received control message: 'PUSH_REQUEST'
Tue Mar 3 18:59:02 2015 raspi/2.240.44.246:26966 send_push_reply(): safe_cap=960
Tue Mar 3 18:59:02 2015 raspi/2.240.44.246:26966 SENT CONTROL [raspi]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)
the output running on the client RPi 2 looks like this (again, after a successful authentication):
Tue Mar 3 18:59:00 2015 [server] Peer Connection Initiated with [AF_INET]2.240.44.246:34345
Tue Mar 3 18:59:02 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Tue Mar 3 18:59:02 2015 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Mar 3 18:59:02 2015 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 3 18:59:02 2015 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 3 18:59:02 2015 OPTIONS IMPORT: route options modified
Tue Mar 3 18:59:02 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 3 18:59:02 2015 ROUTE default_gateway=192.168.2.201
Tue Mar 3 18:59:02 2015 TUN/TAP device tun0 opened
Tue Mar 3 18:59:02 2015 TUN/TAP TX queue length set to 100
Tue Mar 3 18:59:02 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar 3 18:59:02 2015 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Tue Mar 3 18:59:02 2015 /sbin/route add -net 2.240.44.246 netmask 255.255.255.255 gw 192.168.2.201
Tue Mar 3 18:59:02 2015 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.5
Tue Mar 3 18:59:02 2015 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.5
Tue Mar 3 18:59:02 2015 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5
Tue Mar 3 18:59:02 2015 Initialization Sequence Completed
ifconfig returns on server side additionally to lo and eth0:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1907 errors:0 dropped:0 overruns:0 frame:0
TX packets:1820 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:245870 (240.1 KiB) TX bytes:1046186 (1021.6 KiB)
on the client side it looks like this:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.10 P-t-P:10.8.0.9 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:76 (76.0 B) TX bytes:380 (380.0 B)
Here is an image of the structure:
http://i.stack.imgur.com/z9QUs.jpg

In order to access your RPi |2| client from other VPN clients (in your case its iphone), you must know the IP address of the RPi |2| client. In your current scenario, dynamic IP address is assigned to the RPi |2| client each time it establishes new connection with server.
To solve this issue, static IP address must be used for the RPi |2| client. Procedure for setting static IP address of a particular client can be found here.