[Music]
hi my name is Ben and I'm a cloud
support engineer here at the AWS
headquarters in Seattle sometimes
customers ask me why they're unable to
pass traffic over their AWS VPN even
though their tunnel seems to be up in
other cases they report that some
on-premise networks can't communicate
across the VPN while other networks are
able to these anomalies can occur even
though the VPN has been working for a
long time and they've made no recent
changes to their firewall settings if
you're seeing any of these behaviors
then your VPN could be impacted by an
anomaly which we call a security
Association mismatch to investigate this
anomaly let's first consider the type of
firewall that you're using firewalls and
routers affected by this anomaly use a
policy based VPN devices from cisco
juniper FortiGate checkpoint and many
other vendors might use this type of VPN
the main thing to keep in mind is that
policy based VPN is different from what
AWS uses which is route based VPN to
avoid an interoperability issue between
your device in the AWS VPN endpoints you
must apply a special adaptation to your
configuration I'll get more into the
details about the solution in a moment
if you're using a policy based VPN you
have another thing to look at check
whether you've defined more than one
local and remote network statement in
your VPN network policy if you have more
than one rule then this can also cause a
security Association mismatch now let's
talk about interoperability between the
policy based and route based VPN
implementations firewalls that use
policy based VPN rely on policy
statements or ACLs to determine which
traffic they should encrypt or decrypt
over the VPN in this example the
customer Gateway firewall uses a policy
based VPN so we can define a statement
to allow traffic from a local network of
192 168 to a remote network of 170 2.16
with this setup
when network traffic comes into the CGW
firewall and matches this statement it
will form a phase-two security
Association over the VPN tunnel the term
security Association can be abbreviated
as sa NSA is a secure channel used by
specific local and remote
work to communicate with each other in
our example this essay will allow 192
dot 168 and 172 dot 16 to talk with each
other a single essay is composed of an
asynchronous inbound and outbound
encrypted traffic flow however for the
sake of keeping things simple in this
video we'll show this as a high-level
single essay which is assigned a unique
identifier between the VP and peers now
that you understand the concept of an
essay let's continue say that the
customer wants to create two more
Network rules to allow their local
networks of ten dot 255 and 10.0 to
communicate across the VPN with Network
172 dot 16 note that these two
statements will initiate two new unique
essays between the peers this way of
segregating different network traffic
over the VPN works just fine as long as
the remote side of the customer's VPN is
also using a policy based implementation
on their firewall
however AWS does not use policy based
VPNs but instead uses route based VPNs
so what does this mean the AWS Virtual
Private gateway or vgw does not rely on
network rules or policies to determine
which traffic is allowed across the
tunnel instead of egw uses a local route
table lookup and configured next-hop to
determine this traffic because there is
no need to define network rules and keep
traffic segregated by SAS the route
table summarizes all network traffic
into a single essay this single essay
can be randomly selected from all the
essays originally negotiated by the
customer gateway but in our example
let's say it was the last essay formed
this means that the vgw will disregard
all other essays and not use them the
past traffic even though they may remain
installed in memory remember also that
each essay has a unique identifier and
so AWS will assume and use the
identifier of the last essay when
summarizing and sending network traffic
over the tunnel so what kind of issues
occur when using these two different
implementations together let's take our
example again the CGW originally formed
a unique essay for any communication
between 192 dot 168 / 16
the 172 dot 16/16 therefore if any
traffic is sent to it from a remote peer
matching these networks and will expect
encrypted traffic to come in with the
unique identifier that correlates with
the SI however as we stated before AWS
will send all traffic through a single
si the single si ended up being the last
si that the CGW negotiated and has a
different unique identifier from the
first si the CGW will likely drop this
incoming traffic from the vgw
because the unique identifier does not
match the network statements defined
locally luckily for this particular 10.0
network communications between it in AWS
will still work over the VPN tunnel
because the vgw uses its si for all
traffic this explains why some networks
might work over the VPN while others
don't these behaviors address how a
security Association mismatch can occur
and why we might be unable to pass
traffic over the VPN however now another
question arises how is it possible for
traffic to work over the VPN in some
cases but then stop working with no
configuration changes remember that when
the VPN is negotiated the vgw will
randomly choose an SI to summarize all
of its traffic many people think this
VPN negotiation is a manual process they
must perform when creating the VPN on
their firewall for the first time but
really this VPN negotiation can also
happen during phase 1 and phase 2
lifetime Riki's as well as during other
normal IPSec events thanks for watching
and happy cloud computing from all of us
here at AWS
[Music]
you
[Music]