Thoughts on using original_src and translated_src pattern for the attr names over before/after?

from nautobot-app-firewall-models.

NAT Model Proposition

This should be able to cover

• DNAT
• SNAT
• PAT
  for all the use cases I was able to think of.

Similar to the pattern for Any in the AddressObject and ServiceObject realm None means no change in this case.

Model

I want to introduce two new models to this plugin, NATPolicy as an equivalent to Policy and NATPolicyRule as an equivalent to PolicyRule:

• NATPolicy should have all the fields that Policy has, just with nat_rules instead of policy_rules
• NATPolicyRule should have all the fields that PolicyRule has, except that all the following fields are duplicated for before/after - they will however still all be foreign keys - ...
  • source_service
  • source_service_group
  • destination_service
  • destination_service_group
  • source_address
  • source_address_group
  • destination_address
  • destination_address_group
• ...and the following fields are removed
  • action
• For the AddressObject instances that can go into those NATRule fields, forbid FQDN type objects?

Example JSON

The following are quick example JSON files of only those fields that changed in comparison to the non-NAT models and are interesting to the specific example.

Example 1

This model describes a NAT policy that

• PATs the source IP address behind 10.10.10.10/32

{
  "nat_policies":
  {
    "nat_rules": [
      {
        "source_service_before": null,
        "source_service_after": null,
        "destination_service_before": null,
        "destination_service_after": null,
        "source_before": "10.0.0.0/24 (FK to AddressObject)",
        "source_after": "10.10.10.10/32 (FK to AddressObject)",
        "destination_before": null,
        "destination_after": null
      }
    ]
  }
}

Example 2

This model describes a NAT policy that

• DNATs the destination IP address from 1.1.1.1 to 172.16.1.1
• Swaps the destination port of 80/TCP with 8080/TCP

{
  "nat_policies":
  {
    "nat_rules": [
      {
        "source_service_before": null,
        "source_service_after": null,
        "destination_service_before": "80/TCP (FK to ServiceObject)",
        "destination_service_after": "8080/TCP (FK to ServiceObject)",
        "source_before": null,
        "source_after": null,
        "destination_before": "1.1.1.1/32 (FK to AddressObject)",
        "destination_after": "172.16.1.1/32 (FK to AddressObject)"
      }
    ]
  }
}

Example 3

This model describes a NAT policy that

• PATs the source IP addresses from a group behind 10.10.10.10/32

{
  "nat_policies":
  {
    "nat_rules": [
      {
        "source_service_before": null,
        "source_service_after": null,
        "destination_service_before": "80/TCP (FK to ServiceObject)",
        "destination_service_after": "8080/TCP (FK to ServiceObject)",
        "source_group_before": "Internal_Network (FK to AddressObjectGroup)",
        "source_after": "1.1.1.1/32  (FK to AddressObject)",
        "destination_before": null,
        "destination_after": null
      }
    ]
  }
}

Open questions

• Do use cases exist that warrant explicitly changing a source port?
  • This is specifically interesting, because for the use case of many (private) source addresses mapping to few (public) source addresses the source port is implicitly changed, omitting the source_service field family could make this clearer
• Is there a point in having the ServiceGroup field families? I imagine if you will do a destination port translation, then only 1-to-1
• Do we want a mode field to distinguish between static mappings and dynamic mappings? Probably this can be deduced from comparing the before/after counts, but then sometimes maybe you want the mapping to be random?

Happy to hear your thoughts.

from nautobot-app-firewall-models.

@ozmusic - we actually have NAT modelling in 1.1.0 now so you can check it out, its already on the demo. To your first question: In the actual implementation there are two fields, NATPolicyRule.translated_destination_addresses and NATPolicyRule.translated_destination_address_groups, both of which are ManyToManyField instances, meaning that you can assign as many AddressObject/AddressObjectGroup instances as you need.

from nautobot-app-firewall-models.

@davidmclintock Is interested in tracking PAT as well.

from nautobot-app-firewall-models.

+1 for PAT

from nautobot-app-firewall-models.

Some random thoughts...

On point 1 (source port)
Even though I cannot think of a specific use case, most (all?) vendors do support this feature. Also, to bind this with your third point about modes, in Cisco configuration this specific use-case is called "overload".

On point 2 (ServiceGroup)
I've seen this used multiple times as a filter of sorts. You add an original service to tell the firewall to perform NAT only if the requests is towards a specific set of ports. These ports remain un-translated.

from nautobot-app-firewall-models.

@Kircheneer looking at example 2 and destination_after, is there scope in that for destination_after to be a list or is this covered by an address object group?
Something that would be nice to see as well is the addition of a healthcheck field, we could handle that with a custom field for a basic version as the model for a healthcheck may be scope creep here.

from nautobot-app-firewall-models.

@whitej6 I believe this can be closed as the feature is implemented.

from nautobot-app-firewall-models.

@Kircheneer the permissions for the demo user need to be updated to include the nat policies, I'll upgrade our lab instance and check it out there :)

from nautobot-app-firewall-models.

@nniehoff we beed to update permissions for demo

from nautobot-app-firewall-models.