AWS provides support for installing python 3.11 in Amazon Linux 2023 containers.

However it isn't at all obvious how you install and run a compatible pytest in this case.

For example, if you do this:

dnf install -y pytest

the version of pytest installed is the 3.9 version which is compatible with the so-called system version of Python which is 3.9 but is not compatible with python3.11 installed via the supported method.

So what is the canonical way for installing a version of pytest which is compatible with the python3.11 as installed in the manner recommended by AWS?

I have an nginx server block like this, and I am trying to use the proxy_hide_header directive to hide the Content-Security-Policy response header from the proxied server because I am not running an SSL server in a local environment and so the forced upgrade caused by that header is unhelpful.

server {
    include conf.d/environment.conf;
    listen       80;
    server_name  ~^app.*\.acme\..*;

    location / {
        proxy_hide_header "Content-Security-Policy";
        proxy_pass $app_endpoint$uri$is_args$args;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
    }    
}

If I test the nginx proxy with curl:

curl -s -v http://app.acme.io/app/path/ >/dev/null

then this happens:

> GET /app/path/ HTTP/1.1
> Host: app.acme.io
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 
< Server: nginx
< Date: Tue, 02 Jun 2020 14:38:16 GMT
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 4231
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: upgrade-insecure-requests
< Referrer-Policy: strict-origin-when-cross-origin
< 

In other words, the proxy_hide_header directive is not having the expected effect.

[ I know the server block shown is the server block being processed, because it is the only one that references the proxied server of interest and I know that the proxied server is the one being hit. ]

Why isn't the proxy_hide_header directive working in this case?

I've noticed that adding a new disk to an Ubuntu 14.04 VM running on Azure, caused an unconditional reboot of the Azure VM.

When I added a second disk, the VM wasn't rebooted, but the first disk was stolen away and I needed to reboot the VM in order to regain access to the first disk.

This doesn't seem like particularly helpful behaviour.

Is this behaviour documented anywhere?

Updated: Amended with additional details requested in comments.

The procedure I used to attach a new disk was cribbed basically from here:

https://azure.microsoft.com/nl-nl/documentation/articles/virtual-machines-linux-how-to-attach-disk/

with some differences.

This procedure below describes what I did to add a second extra disk (sdd). Last week I did something similar to add a first extra disk (sdc). In that case, the system rebooted by itself. In this case, the system did not reboot itself, but I did lose access to /dev/sdc as soon as I added the new disk.

Note that I didn't use the azure cli to allocate or attach the new disk. Rather, I used the web portal.

Once I did that, I then used:

dmesg | grep scsi

to discover that the new device was called /dev/sdd

Dec 16 14:00:58 azure kernel: [ 2.696851] sd 5:0:0:1: [sdd] Attached SCSI disk

I then formatted the disk with fdisk, per the instructions in the article above.

I then mounted the disk and proceded to rsync the filesystem tree I was moving onto the disk.

It was then that I noticed that the previous disk (sdc) that I had attached last week (the one that caused a reboot) was no longer accessible. (It wasn't visible in blkid, either).

I have since discovered these messages in kern.log which indicate that (sdc) became inaccessible almost as soon as I had completed the attach disk action in the portal (e.g. before I had discovered the new disk by scanning dmesg)

Dec 16 13:23:34 azure kernel: [538544.870108] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:34 azure kernel: [538544.870267] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538545.824751] hv_storvsc vmbus_0_16: cmd 0x2a scsi status 0x0 srb status 0x20
Dec 16 13:23:35 azure kernel: [538545.824846] end_request: I/O error, dev sdc, sector 130548832
Dec 16 13:23:35 azure kernel: [538545.828189] Aborting journal on device sdc1-8.
Dec 16 13:23:35 azure kernel: [538545.830301] JBD2: Error -5 detected when updating journal superblock for sdc1-8.
Dec 16 13:23:35 azure kernel: [538545.836606] end_request: I/O error, dev sdc, sector 0
Dec 16 13:23:35 azure kernel: [538546.308389] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Dec 16 13:23:35 azure kernel: [538546.308528] hv_storvsc vmbus_0_16: cmd 0x35 scsi status 0x0 srb status 0x20
Dec 16 13:23:35 azure kernel: [538546.309513] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.309776] scsi 5:0:0:1: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 4
Dec 16 13:23:35 azure kernel: [538546.310764] sd 5:0:0:1: Attached scsi generic sg2 type 0
Dec 16 13:23:35 azure kernel: [538546.311251] sd 5:0:0:1: [sdd] 268435456 512-byte logical blocks: (137 GB/128 GiB)
Dec 16 13:23:35 azure kernel: [538546.311254] sd 5:0:0:1: [sdd] 4096-byte physical blocks
Dec 16 13:23:35 azure kernel: [538546.311265] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.312429] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.312737] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.313289] sd 5:0:0:1: [sdd] Write Protect is off
Dec 16 13:23:35 azure kernel: [538546.313293] sd 5:0:0:1: [sdd] Mode Sense: 0f 00 10 00
Dec 16 13:23:35 azure kernel: [538546.313750] sd 5:0:0:1: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
Dec 16 13:23:35 azure kernel: [538546.326335]  sdd: unknown partition table
Dec 16 13:23:35 azure kernel: [538546.328228] sd 5:0:0:1: [sdd] Attached SCSI disk
Dec 16 13:23:35 azure kernel: [538546.446399] hv_storvsc vmbus_0_16: cmd 0x85 scsi status 0x2 srb status 0x86
Dec 16 13:23:35 azure kernel: [538546.446404] hv_storvsc vmbus_0_16: stor pkt ffff880159d31180 autosense data valid - len 18
Dec 16 13:23:35 azure kernel: [538546.446406] storvsc: Sense Key : Illegal Request [current] 
Dec 16 13:23:35 azure kernel: [538546.446409] storvsc: Add. Sense: Invalid command operation code
Dec 16 13:23:35 azure kernel: [538546.446495] hv_storvsc vmbus_0_16: cmd 0x85 scsi status 0x2 srb status 0x86
Dec 16 13:23:35 azure kernel: [538546.446498] hv_storvsc vmbus_0_16: stor pkt ffff880159d31180 autosense data valid - len 18
Dec 16 13:23:35 azure kernel: [538546.446499] storvsc: Sense Key : Illegal Request [current] 
Dec 16 13:23:35 azure kernel: [538546.446501] storvsc: Add. Sense: Invalid command operation code

My reading of these messages is that SCSI subsystem in Ubuntu 14.04 doesn't like whatever Azure is doing to announce new disks and, in fact, loses track of disks already attached.

Other notes:

• the previously added disk sdc did not appear in blkid until the next reboot
• upon reboot, /dev/sdc was usable again (although, of course, it had to be fsck'd and the databases on it were survived as well as databases survive when the disk is ripped out with no warning)

I am trying to duplicate UDP packets flowing to port 50007 on an Internet address from devices on a local NAT network (192.168.12.0/24) with the intent of processing them locally (on 192.168.12.1:50006).

On 38 of my 40 devices, the following iptables mangle and nat tables do the trick - port 50006 receives packets at the transmitted rate of 12 per minute - 1 per 5 seconds.

However, on two devices, that have an identical configuration as the other 38, port 50006 receives packets at rate of 1/11th of the transmitted rate, e.g. 1 packet every 55 seconds - the other 10 of 11 packets presumably being dropped.

Port 50006 is listened to by a socat script:

socat UDP-RECVFROM:50006,fork "EXEC:handler-script"

The handler script returns within 1 second and no change in receipt rate is observed when the script is changed to be a no-op.

One of the two malfunctioning devices spontaneously corrected itself and port 50006 started to receive packets at the transmitted rate.

The remaining device is still only receiving packets 1/11th of the transmitted rate, even though tcpdump shows the original packets arriving at the full rate.

$ sudo iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
TEE        udp  --  192.168.12.0/24      anywhere             udp dpt:50007 TEE gw:10.0.0.1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  192.168.12.0/24      anywhere             udp dpt:50007 to:192.168.12.1:50006

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  192.168.12.0/24      anywhere            

One oddity with the malfunctioning node is that tcpdump shows the duplicated packet with the original source address and the source address corresponding to the local node's IP on the uplink. On the working nodes, tcpdump only shows the original (pre-masqueraded) packet.

$ sudo tcpdump -i eth2 port 50007

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
03:56:41.851719 IP 192.168.12.66.4097 > example.com.50007: UDP, length 216
03:56:41.851996 IP 10.0.0.8.4097 > example.com.50007: UDP, length 216`

CPU on the malfunctioning node appears nominal and there are almost certainly no configuration differences between the functioning and malfunctioning nodes. The nodes are, however, deployed in different LANs.

So the question is: what could be causing the malfunctioning node to be dropping 10 out of every 11 packets? A second question is: why does is tcpdump behaving differently on this node and showing the masqueraded packet as well as the original packet.

Any suggestions about how I might go about debugging this issue?

While debugging a problem with the networking configuration for a set of virtual machines running under KVM, I discovered a circumstance where the kernel in the guest VM has decided to stamp the outgoing Ethernet frame with a destination address that is in conflict with the address it would choose if it was respecting with the kernel IP route table.

So, in that example, I expected the outbound frame to be delivered to de:ad:be:3b:24:48 which corresponds to the host that owns the IP address 10.11.11.2 and that owns a route to 10.8.0.0/24.

What actually happened is that the kernel decided to stamp the frame with a destination of 00:10:db:ff:70:01 which sent the frame in the direction of 10.11.11.1 which doesn't know how to route to 10.8.0.0/24 and as a result the packet was dropped.

This decision was in contravention of the local routing table that clearly specified that the route to 10.8.0.0/24 was via 10.11.11.2. See the original problem report for details.

[The incorrect destination address was visible by running tcpdump in the guest VM that was sending the frame in the incorrect direction.].

In fact, by kludging the local arp table to make 10.11.11.1's apparent MAC address to be identical to 10.11.11.2's actual MAC address, I was able to get the frame flowing in the correct direction.

So my question is: what mechanism, in either the guest VM or the KVM host, could cause the guest kernel to ignore the local route table and send the packet in a frame towards the (incorrect) host at 10.11.11.1, even though 10.11.11.1 wasn't listed as a gateway for the destination network (10.8.0.0/24)?

Note: iptables was disabled in the guest at the time. I don't know if ebtables is enabled in the KVM host, but even if it was, how would this cause the kernel in the guest VM to want send the packet in the direction of 10.11.11.1?

One behaviour I did notice is that if I purge the ARP tables of the affected host and send a ping request to the affected host from the 10.8.0.0/24 network, it receives the request, then sends an arp broadcast for 10.11.11.1 immediately prior to sending the ping response in the direction of 10.11.11.1 instead of 10.11.11.2 and hence 10.8.0.0/24. What is causing it to try 10.11.11.1 which is not specified as a gateway?

In a previous question, I was trying to determine why my OpenVPN clients could not ping the server LAN, even though the server LAN could ping the clients.

Having investigated this further, I determined that, at least in the case of one of the servers, the problem results from a decision by the kernel to forward an Ethernet frame containing the ping reply in the direction of a MAC address that doesn't know how to route the packet.

So, for example:

10.11.11.7 de:ad:be:7f:45:72 
10.11.11.1 00:10:db:ff:70:01
10.11.11.2 de:ad:be:3b:24:48 

Pings from 10.11.11.7 to 10.8.0.10 work. Ping requests from 10.8.0.10 to 10.11.11.7 arrive as expected, but replies never reach 10.8.0.10 apparently because they are routed in the direction of 10.11.11.1 instead of 10.11.11.2 which contains the VPN server that can route to 10.8.0.0/24.

For example:

When I try to ping 10.8.0.10 from 10.11.11.7, the request leaves on the interface containing 10.11.11.2 which contains the VPN gateway that can reach 10.8.0.10.

01:46:39.973670 de:ad:be:7f:45:72 > de:ad:be:3b:24:48, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.11.11.7 > 10.8.0.10: ICMP echo request, id 49247, seq 6, length 64
0x0000:  4500 0054 0000 4000 4001 1b86 0a0b 0b07  E..T..@.@.......
0x0010:  0a08 000a 0800 37a4 c05f 0006 7ff8 5f4f  ......7.._...._O
0x0020:  0000 0000 53db 0e00 0000 0000 1011 1213  ....S...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

The expected response arrives via the reverse path...

01:46:40.145368 de:ad:be:3b:24:48 > de:ad:be:7f:45:72, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  63, id 53200, offset 0, flags [none], proto: ICMP (1), length: 84) 10.8.0.10 > 10.11.11.7: ICMP echo reply, id 49247, seq 6, length 64
0x0000:  4500 0054 cfd0 0000 3f01 8cb5 0a08 000a  E..T....?.......
0x0010:  0a0b 0b07 0000 3fa4 c05f 0006 7ff8 5f4f  ......?.._...._O
0x0020:  0000 0000 53db 0e00 0000 0000 1011 1213  ....S...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

On the other hand, when 10.8.0.10 pings 10.11.11.7, the ping request is received on the expected interface:

01:46:11.734359 de:ad:be:3b:24:48 > de:ad:be:7f:45:72, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.8.0.10 > 10.11.11.7: ICMP echo request, id 15635, seq 74, length 64
0x0000:  4500 0054 0000 4000 3f01 1c86 0a08 000a  E..T..@.?.......
0x0010:  0a0b 0b07 0800 c1ff 3d13 004a 65f8 5f4f  ........=..Je._O
0x0020:  0000 0000 7088 0400 0000 0000 1011 1213  ....p...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

but it leaves in the direction of 10.11.11.1, instead of 10.11.11.2:

01:46:11.734383 de:ad:be:7f:45:72 > 00:10:db:ff:70:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  64, id 41757, offset 0, flags [none], proto: ICMP (1), length: 84) 10.11.11.7 > 10.8.0.10: ICMP echo reply, id 15635, seq 74, length 64
0x0000:  4500 0054 a31d 0000 4001 b868 0a0b 0b07  [email protected]....
0x0010:  0a08 000a 0000 c9ff 3d13 004a 65f8 5f4f  ........=..Je._O
0x0020:  0000 0000 7088 0400 0000 0000 1011 1213  ....p...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

This is unexpected, because the route table on 10.11.11.7 is configured as follows:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.11.11.2     255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.11.11.2     0.0.0.0         UG    0      0        0 eth0

So, my question is: why is the kernel sending the ping response in the direction of 10.11.11.1, even though the gateway is defined as 10.11.11.2?

Update:

By polluting the arp cache in 10.11.11.7 with a mac address for 10.11.11.1, that actually points at 10.11.11.2 e.g.:

sudo /sbin/arp -s 10.11.11.1 de:ad:be:3b:24:48

I was able to get ping from 10.8.0.10 to 10.11.11.7 working as expected.

Obviously, this was just for purposes of demonstration. Why is my kernel choosing the wrong destination MAC address in the first place?

Update 2:

According to lsmod, the network driver is probably:

virtio_net             48449  0 

which indicates, perhaps, that the virtual machine is running under KVM.

Update 3:

This question was answered with ptman's suggestion to consider policy and source based routing in his answer to another question of mine.

Thank you, ptman!

We are in the process of setting up an OpenVPN server for some servers running in a cloud. We are stumped with a connectivity problem whereby the hosts on the VPN server's LAN can ping te VPN client, but the reverse is not true.

The VPN client can ping the VPN server on its VPN address, but not on its LAN address.

tcpdump shows evidence of ping packets from the client reaching the host and replies being issued, but for some reason the replies never reach the tun0 interface on the VPN server or the client. Conversely, traffic for the ping requests from the VPN server's LAN to the VPN client are seen on all the expected interfaces, according to tcpdump.

A detailed description of our configuration and troubleshooting to date is given below.

The problem appears to be related to forwarding from addresses on the server's network back to the client network. What is really odd (to me) is that the LAN initiated pings can do the full round trip, but client initiated pings seem to get dropped somewhere between the VPN server's tun0 and eth1 interfaces.

What are we missing?

Situation:

3 hosts:

• VPN client (tun0: 10.8.0.22)
• VPN server (tun0: 10.8.0.1, eth1: 10.11.11.2, eth0: x.x.x.x)
• LAN server (eth0: 10.11.11.7)

Both servers are virtual machines, running RHEL 5.7. I think (but am not entirely sure) that the virtual hosting environment is VMWare.

Tests

• VPN client has established tunnel to VPN server, via the VPN server's eth0 interface
• VPN client can ping the VPN server on its tun0 interface 10.8.0.1
• VPN server can ping 10.8.0.22
• LAN server can ping 10.8.0.22

but:

• VPN client cannot the ping VPN server on its eth1 interface 10.11.11.2
• VPN client cannot the ping LAN server on its eth0 interface 10.11.11.7

For the ping test between 10.11.11.7 and 10.8.0.22:

• tcpdump shows ping requests and replies traversing tun0 on VPN server
• tcpdump shows ping requests and replies traversing eth1 on VPN server
• tcpdump shows ping requests and replies traversing eth0 on LAN server

For the ping test between 10.11.11.2 and 10.8.0.22:

• tcpdump shows ping requests and replies traversing tun0 on VPN server

For the ping test between 10.8.0.22 and 10.11.11.2:

• tcpdump shows ping requests traversing tun0 on VPN server
• tcpdump shows ping replies traversing eth1 on VPN server
• there is no trace of the reply on the tun0 interface

For the ping test between 10.8.0.22 and 10.11.11.7:

• tcpdump shows ping requests traversing tun0 on VPN server
• tcpdump shows ping requests traversing eth1 on VPN server
• tcpdump shows ping requests traversing eth0 on LAN server
• tcpdump shows ping replies traversing eth0 on LAN server
• there is no trace of the reply on either the tun0 or eth1 interfaces of the VPN server

ip_fowarding has been enabled on the VPN server rp_filter has been disabled on the VPN server for all interfaces except the internet facing interface, eth0.

iptables has been disabled with (default ACCEPT) rules on the client for the purposes of debugging the underlying issue.

I have included dumps of the route -n and ifconfig for the relevant interfaces on each host.

On the OpenVPN server

$ /sbin/route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
x.x.x.x     0.0.0.0         255.255.248.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         x.x.x.x     0.0.0.0         UG    0      0        0 eth0

$ find /proc/sys/net -name 'rp_filter' | while read f
> do echo $f $(cat $f)
> done
/proc/sys/net/ipv4/conf/tun0/rp_filter 0
/proc/sys/net/ipv4/conf/eth1/rp_filter 0
/proc/sys/net/ipv4/conf/eth0/rp_filter 1
/proc/sys/net/ipv4/conf/lo/rp_filter 0
/proc/sys/net/ipv4/conf/default/rp_filter 0
/proc/sys/net/ipv4/conf/all/rp_filter 0

$ cat /proc/sys/net/ipv4/ip_forward 
1

$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   


$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:A6:28:21  
          inet addr:x.x.x.x  Bcast:x.x.x.x  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:233929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24776 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27881415 (26.5 MiB)  TX bytes:30534780 (29.1 MiB)

eth1      Link encap:Ethernet  HWaddr DE:AD:BE:3B:24:48  
          inet addr:10.11.11.2  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:423658 (413.7 KiB)  TX bytes:863546 (843.3 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11992 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34820967 (33.2 MiB)  TX bytes:34820967 (33.2 MiB)

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:69 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:5796 (5.6 KiB)  TX bytes:4788 (4.6 KiB)

$ uname -a
Linux vhost0273 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=64 time=145 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 145.676/145.676/145.676/0.000 ms

$ ping -c1 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.
64 bytes from 10.11.11.7: icmp_seq=1 ttl=64 time=0.794 ms

--- 10.11.11.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.794/0.794/0.794/0.000 ms

On a host on the server LAN:

$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:7F:45:72  
          inet addr:10.11.11.7  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33897 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2536157 (2.4 MiB)  TX bytes:8910725 (8.4 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:77779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77779 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.11.11.2      255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.11.11.2      0.0.0.0         UG    0      0        0 eth0

$ ping -c1 10.8.0.1 -w 1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.516 ms

--- 10.8.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.516/0.516/0.516/0.000 ms

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=63 time=146 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 146.913/146.913/146.913/0.000 ms

$ ping -c1 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.
64 bytes from 10.11.11.2: icmp_seq=1 ttl=64 time=0.775 ms

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.775/0.775/0.775/0.000 ms

On the VPN client

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.22  P-t-P:10.8.0.21  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

$ /sbin/route -n | grep ^10
10.8.0.21       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.0.1.0        0.0.0.0         255.255.255.0   U     2      0        0 wlan0
10.1.1.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.11.11.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=145 ms

$ ping 10.8.0.2 -w 1
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.

--- 10.8.0.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.

--- 10.11.11.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms