I have a bridged OpenVPN setup on a Linux server in an Amazon EC2 VPC. (Spent hours on docs, reading similar problems, here, openVPN forums, no luck yet.)
The bridged interface is up and contains both sub-interfaces:
# brctl show bridge name bridge id STP enabled interfaces br0 8000.0e7c15e787b0 no eth0 tap0
Routing is obviously OK on the VPN server; I can SSH in, ping around, respond to the VPN request from the client:
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 br0 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
I can ping from both Windows & Mac clients to the VPN server's IP but not to any other IP's on the VPC subnet. (Those other IP's are OK; they are pingable from the VPN server.)
tcpdump on the bridge interface
br0 on the VPN server it sees the "ARP who-has" requests from the Windows client. However they aren't going onto the VPC subnet!
tcpdump on the destination IP does not see the ARP arrive. The Windows arp cache remains unfilled. (10.0.0.128 is the Windows client; 10.0.0.58 is the VPN server; 10.0.0.180 is the other IP on the subnet; the output below is from the VPN server.)
root@vpn:# tcpdump -i br0 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes 21:00:21.092367 ARP, Request who-has 10.0.0.180 tell 10.0.0.128, length 28
I have disabled the Source/Dest. check within the EC2 console on the VPN server's sole network interface.
I have set up the IP tables as recommended in the bridging HOWTO, and generally followed these instructions exactly.
# iptables -L INPUT -v Chain INPUT (policy ACCEPT 9 packets, 1008 bytes) pkts bytes target prot opt in out source destination 38 12464 ACCEPT all -- tap0 any anywhere anywhere 10447 1297K ACCEPT all -- br0 any anywhere anywhere # iptables -L FORWARD -v Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 918 167K ACCEPT all -- br0 any anywhere anywhere
I don't think I need to dump the full configs because obviously a lot is working: authentication, certs, compression, address pool, connection set-up generally. Does the Amazon VPC simply refuse to forward packets and I should really be on a somewhat-less-virtual cloud to do this?
MORE EXPERIMENTS THE NEXT DAY:
The VPC clearly isn't behaving like a true layer 2 subnet. In particular, ARP
who-has broadcasts don't actually broadcast! When I ping a non-existent IP (say .5) from .180, .58 doesn't see the request. The VPC is obviously optimizing away ARP broadcasts and sending it only to .5, if a .5 has been configured in the VPC via management console / API. Leaving
tcpdump -vv -i eth0 arp on for a while only shows traffic between the host and the gateway, for all hosts.
Further, pinging the broadcast address on the subnet doesn't work at all. This is backed up by the Amazon VPN FAQ.
So the VPC is likely refusing to recognizing the unknown MAC address of .129, since it doesn't exist in its own "virtual ethernet switch". I'll probably shift this as the answer in a week or so. To extend the VPC with your own VPN, it must be via the formal "VPC gateway", which is only designed to work as an extension of a corporate intranet backed by a dedicated hardware router and static IP, not the roaming laptop scenario I'm aiming for.