Access Server Full Tunnel on EC2: Why One Checkbox Is Not Enough

Clearing source/destination checking on an EC2 instance is the most repeated answer to Access Server internet-egress questions, and on its own it does nothing for your clients. The check is an AWS forwarding constraint: it makes the instance accept packets whose source or destination is not its own address. It does not tell the Access Server client to send internet traffic through the tunnel, does not create an upstream route, and does not add NAT. The myth is that the checkbox is the feature.

What the check actually controls

Every EC2 network interface drops traffic that is not addressed to it, unless the instance is acting as a router, NAT device or VPN gateway and you disable that check. Disabling it grants permission to forward. Permission is not configuration: the instance still needs a route to an internet gateway or NAT device, the VPC route table still needs the matching entry, security groups still have to allow the flow, and the server still has to translate or route the return traffic.

Verify the current value with aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck before changing anything. If you change it in the console, change it because the instance forwards for others, not because a client cannot reach the internet.

Access Server owns the client routing policy

In Access Server 3, open Access Controls and find the Internet Access and DNS section. The Internet Gateway selection offers full tunnel or split tunnel; full tunnel tells the client to route its default traffic into the VPN, split tunnel leaves internet traffic on the client's local path. Save and apply through the product workflow, then reconnect a test client, because the policy is delivered at connection time.

Older releases use different menus and some Community OpenVPN builds have no equivalent control. Check the installed major version before hunting for a screen that does not exist. Then confirm what the client received: a full-tunnel profile should install a default route through the tunnel, and a split-tunnel profile should not.

Trace the packet after the tunnel

Once the client sends internet traffic into the tunnel, the server must forward it and usually translate it. Access Server manages its own NAT and routing rules, so read the effective configuration instead of appending Community OpenVPN rules to generated files; unmanaged rules get overwritten or conflict on the next product update. sudo iptables -t nat -L -n -v or the nftables equivalent shows what is actually translating.

The AWS side is a separate path. A public-subnet instance reaches an internet gateway directly and keeps its public address or elastic IP. A private-subnet instance needs a route to a NAT gateway or NAT instance, and the NAT device needs its own route to the internet gateway. Attaching an internet gateway to the VPC gives no private source a public return address by itself, which is why the same Access Server setup works in one subnet and silently fails in another.

Check the route table associated with the instance subnet, not just the VPC main table. Subnet associations override the main table, and a stale association is a common reason a working configuration stops after a rebuild.

Keep IP egress and DNS separate

Test an address literal first, then a name, from the same client application. If curl -4 https://checkip.amazonaws.com returns a public address but hostnames fail, the tunnel and NAT path work and the problem is DNS: the pushed resolver, the client's resolver state, or a security group blocking the resolver. The Access Server DNS settings live in the same Internet Access area, but they travel a different code path.

Compare the returned address with the egress you intended. If it is the instance public address, traffic is being translated by the instance; if it is a NAT gateway address, the private-subnet path is in use. Either can be correct. What you cannot conclude is that a browser on the server proves client forwarding.

Do not let one checkbox close the investigation

IPv6 is a separate decision. A full-tunnel policy for IPv4 says nothing about whether IPv6 is carried, blocked or leaked, and a dual-stack client can keep using its local IPv6 path while IPv4 is tunnelled. Test the address family you actually care about, and decide explicitly whether the other one should be disabled.

Finally, test the disconnected state. A full-tunnel selection describes connected routing policy, not what happens when the tunnel drops. If the requirement is that no traffic escapes outside the VPN, that is a kill-switch and firewall question, and it needs its own test rather than an inference from the routing table.