Archive for the ‘NAT’ Category
Error message in the Tracker : NAT Hide failure – there are currently no available ports for hide operation
Can happen when the fwx_alloc table is full :
#fw tab -t fwx_alloc -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost fwx_alloc 8187 150000 150000 0
#fw tab -t fwx_alloc
localhost:
——– fwx_alloc ——–
dynamic, id 8187, attributes: keep, sync, expires never, limit 150000, hashsize 131072
[...]
You can flush the table with the following command:
#fw tab -t fwx_alloc -x
FYI:
The fwx_cache table was introduced in VPN-1/ FireWall-1 NG FP3 and VPN-1/ FireWall-1 NG AI. The table is used as a cache for the NAT rule matched entries. If a specific connection (i.e. specific source IP address -> specific destination IP address) matches a NAT rule, the result of the rule match will be kept in this table. When the next such connection opens, the NAT rule match will not be performed, since that information is already in the cache table. The NAT cache table is intentionally smaller than the Connections table, since it is assumed that it will contain most of the common / frequent connections, therefore enabling NAT performance optimization.
Before VPN-1 NGX, all NAT occurred at the “server side” of the kernel, i.e., on
the outbound side of the kernel closest to the server. When NAT occurs in this
configuration, address spoofing and routing must be configured correctly.
As ofVPN-1 NGX, the default method for Destination NAT is “client side”,
where NAT occurs on the inbound interface closest to the client. Assume the
client is outside the Gateway, and the server is inside the Gateway with
automatic Static NAT configured. When the client starts a connection to access
the server’s NAT IP address, the following happens to the original packet in a
client-side NAT:
ORIGINAL PACKET
1. The packet arrives at the inbound interface, and passes Security Policy
rules.
2. If accepted, the packet is entered into the connections table.
3. The packet is matched against NAT rules for the destination. The packet is
translated if a match is found.
4. The packet arrives at the TCP/IP stack of the NGX Gateway, and is routed
to the outbound interface.
The packet is translated, so it is routed correctly without any need
to add a static route to the Gateway.
5. The packet goes through the outbound interface, and is matched against
NAT rules for the source.
6. NAT takes place, if a match is found for translating the source.
7. The packet leaves the Security Gateway.
REPLY PACKET
1. The reply packet arrives at the inbound interface of the Gateway.
2. The packet is passed by the Policy, since it is found in the connections table.
3. The packet’s destination, which is the source of the original packet, is
translated according to NAT information in the tables.
4. The packet arrives at the TCP/IP stack of the Gateway, and is routed to the
outbound interface.
5. The packet goes through the outbound interface. The packet’s source, the
destination of the original packet, is translated according to the information
in the NAT tables.
6. The packet leaves the Gateway.