4
Correct. The ASAv does not support the FirePOWER NGFW functionality. I’m not sure what your options are for wherever this is going but most manufacturers make a virtual appliance, and most others do support what you want. We can’t give recommendations here but, I have virtual Fortigate units for some clients that work well.
4
I found the solution to this eventually, with some help.
The issue was that on the ASR side, the tunnel was in its default configuration which uses GRE, which the ASA doesn't support.
The solution was to change the tunnel mode to ipsec ipv4 like so:
interface Tunnel5
tunnel mode ipsec ipv4
With this done, bidirectional traffic was possible over the tunnel.
4
Keep in mind that networking in the cloud works a bit differently than it does in the real world. ARP for instance does not work as you would expect: it's the cloud controller that answers the ARP request, not the device on which the IP address is configured. This means that Azure must know at all times what IP addresses are on what devices.
In order to ...
3
Because you don't currently have any group-url or group-alias definitions on any tunnel-groups, your users will use DefaultWEBVPNGroup's settings, which use local authentication (rather than something like RADIUS, TACACS, or LDAP) and will use the default group-policy DfltGrpPolicy.
Because of this, you have 3 options.
Option 1: You can edit DfltGrpPolicy so ...
3
What you want is called a VPN-filter. It’s just a normal extended ACL, but how you apply it is what makes it a “VPN-filter”.
So, if you want to allow your VPN subnet to only talk with something specific, you would build an ACL such as:
access-list VPN-Filter extended permit tcp 192.168.100.0 255.255.255.0 host 192.168.200.200 eq 3389
access-list VPN-Filter ...
3
Ok apparently that's what the Splunk plugin does as well.
See "Splunk Add-on for Cisco ASA" https://splunkbase.splunk.com/app/1620/
# direction is inbound
[cisco_asa_message_id_302013_302015_inbound]
REGEX = -30201[35]:\s*(\S+)\s+([Ii]nbound)\s+(\S+)(?:\s+connection)?\s+(\d+)\s+for\s+([^:\s]+)\s*:\s*(?:((?:[\d+\.]+|[a-fA-F0-9]*:[a-fA-F0-9]*:[a-fA-...
3
The packet-tracer command.
For example:
packet-tracer input inside tcp 192.168.1.100 1234 8.8.8.8 443 would show you each phase/stage of the flow process including which NAT (if any), which ACL (if any), which route statement (if any), and which interfaces are involved in either allowing or denying the flow, along with whether the traffic was a part of a ...
3
You're creating an asymmetric routing situation. The destination may be different, but the source will be the same, so return traffic will always flow across the same ("default") tunnel.
One way to get around this is to do "twice nat"; rewrite source and destination. This doesn't necessarily have to happen on the same ASA, but often makes ...
2
object network obj-SERVER
host <SERVER>
!
object network obj_any
subnet 0.0.0.0 0.0.0.0
!
object service dest-tcp-REAL
service tcp destination eq <REAL>
object service dest-tcp-MAPPED
service tcp destination eq <MAPPED>
!
nat (outside,inside) source static obj_any interface destination static interface obj-SERVER service dest-tcp-...
2
So, as I said, you can mostly accomplish what you want (minus an actual object-group to reference in a single NAT statement).
You'll need to create multiple objects all pointed to the same host IP address, but named differently; this will allow you to map multiple ports to the same host without mapping ALL ports and protocols to said host (it will only map ...
2
You could write your firewall rules so that the "noisy" communication falls into a dedicated "Allow" rule and turn off logging for such rule.
2
On your router, all of your static routes pointing to your firewall are wrong. You need to define the next hop since you aren’t on a PTP link.
Please remove all of the routes pointing to Eth0/1 using the commands:
no ip route 192.168.10.10 255.255.255.255 Ethernet0/1
no ip route 209.165.200.227 255.255.255.255 Ethernet0/1
no ip route 209.165.200.228 255.255....
1
It's not just NAT but also routing in your case.
For NAT this should do:
nat (inside,outside) after-auto source dynamic any interface
For routing you will need to route "inside" networks to your inside router:
route inside 192.168.10.0 255.255.255.0 172.16.0.1
route inside 192.168.20.0 255.255.255.0 172.16.0.1
route inside 192.168.30.0 255.255.255....
1
First, yes, Packet Tracer is extremely limited. It’s a learning tool for passing exams, so it lacks TONS of functionality that real devices have.
As for your main question, absolutely you can do that. Your inside interface, as you have it configured, looks to be simply an access segment to something else (likely a switch), where your real inside network ...
1
Do yourself a favor and don't use NAT where it's not required. You're tunneling between private address areas and there's no address collision, whence no need to complicate things with using NAT.
Once you're routing transparently, you've simply got two paths between the networks. I'd use policy routing with fall back. ECMP requires session tracking and ...
Only top voted, non community-wiki answers of a minimum length are eligible