Hi, Ross,

Thanks for asking about this. Rules for traffic egressing CF containers are
controlled by whitelist-style security groups defined in CC and bound
either system-wide or to individual spaces. The docs for configuring them
are located at http://docs.cloudfoundry.org/adminguide/app-sec-groups.html.

The default security groups allow DNS traffic anywhere (port 53 on TCP and
UDP) and traffic to public IP space, which are seeded in the minimal
manifest at https://github.com/cloudfoundry/cf-release/blob/
v254/example_manifests/minimal-aws.yml#L631-L642 and which correspond
to the rules you see in that iptables output. So in your case, you'll need
to add a security group for access to the VPN network in private IP space
and bind it system-wide as both a staging and a running security group.
Here are the steps you would take to do that with the CF CLI as an admin
user:

- Create a "vpn" security group with the cf create-security-group command,
which involves putting the security group definition into a file and
supplying that to the command:

echo '[{"protocol":"all","destination":"192.168.0.0/24","description":"VPN"}]'

vpn.json

cf create-security-group vpn vpn.json

If you use bash or a similar shell with process substitution, you can
inline the definition instead of creating that separate file:

cf create-security-group vpn <(echo '[{"protocol":"all","destination":"
192.168.0.0/24","description":"VPN"}]')

- Bind that new "vpn" security group system-wide:

cf bind-staging-security-group vpn
cf bind-running-security-group vpn

You'll then have to restart the apps for the new security group rules to
take effect.

Best,
Eric, CF Diego PM


On Thu, Mar 30, 2017 at 6:57 AM, Ross Mark <ross.mark(a)s4-technology.com>
wrote:

This is my first time setting up bosh and cloud foundry on an AWS
environment. Appologies if I'm asking this in the wrong group.

I've implemented the cf deployment using the minimal-aws.yml example as
basis. The problem I'm facing is that our applications need to access a
remote network via VPN with a 192.168.0.0/24 address. The VPN is working
happily, dns using our own internal dns server is resolving correctly so
the cf deployed containers can resolve the address they need however when
they try and access any of the 192.168.0.x addresses (except dns) the
requests are never forwarded from the internal 10.254.0.2 network. Looking
at the iptables rules on the diego_cell vm (iptables -L -n -v) the problem
appears to be in the w--forward chain which after checking the
w--instance-c56ch9ro828 chain, which generates a RETURN, then DROPS the
request.

What I'm looking for is how to configure the deployment so that network
address 192.168.0.0/24 are ACCEPTED for forwarding. I have tested by
manually adding an ACCEPT rule in the w--forward chain, and there is full
connectivity once a rule is added.

The iptables output (trimmed to just include the FORWARD chains) is below.

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
327 36110 w--forward all -- w+ * 0.0.0.0/0
0.0.0.0/0

Chain w--forward (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- eth0 * 0.0.0.0/0
0.0.0.0/0
67 6522 w--instance-c56ch9ro828 all -- wbrdg-0afe0000 *
10.254.0.2 0.0.0.0/0 [goto] /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

Chain w--instance-c56ch9ro828 (1 references)
pkts bytes target prot opt in out source
destination
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 192.169.0.0-255.255.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
59 5016 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 172.32.0.0-192.167.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 169.255.0.0-172.15.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 11.0.0.0-169.253.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-9.255.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 224 RETURN udp -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 udp
dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN tcp -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 tcp
dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 ACCEPT all -- * * 10.254.0.0/30
10.254.0.0/30 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 1282 w--default all -- * * 0.0.0.0/0
0.0.0.0/0 [goto] /* 275382a7-82d6-4d20-7



Thanks in advance.

Ross