cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2666
Views
10
Helpful
5
Replies

NAT/PAT and VFR

bazzaroo
Level 1
Level 1

Hi everyone,

I've been hunting around the web trying to find out why virtual fragmentation reassembly is automatically configured on interfaces that are configured for NAT but have been unable to find a solid answer. I've speculated it might be because non-initial fragments wouldn't be able to be translated due to the missing layer 4 information but I've not been able to have that confirmed. Does anybody have a definite answer?

Thanks,

Barry

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Barry,

I believe you are spot on. When performing PAT, you are relying on the transport protocol port to uniquely and unambiguously identify the particular entry in the translation table according which the packet should be translated. If a TCP or UDP segment is overly large, it is naturally fragmented into several IP packets. However, the TCP or UDP headers would be present only in the first fragment, the remaining fragments would contain only the payload portion of the original segment. That would mean, however, that the router would not be able to unambiguously tell (using just the IP address and no L4 information) according to which entry in the translation table shall this packet be translated.

The VFR helps here. Although it does not defragment whole packets, it still allows to keep track of several fragments that constitute a single original packet, and deal with them as if they were a single large packet with all L4 information present.

Does this help a little? Please feel welcome to ask further!

Best regards,

Peter

View solution in original post

5 Replies 5

Peter Paluch
Cisco Employee
Cisco Employee

Hello Barry,

I believe you are spot on. When performing PAT, you are relying on the transport protocol port to uniquely and unambiguously identify the particular entry in the translation table according which the packet should be translated. If a TCP or UDP segment is overly large, it is naturally fragmented into several IP packets. However, the TCP or UDP headers would be present only in the first fragment, the remaining fragments would contain only the payload portion of the original segment. That would mean, however, that the router would not be able to unambiguously tell (using just the IP address and no L4 information) according to which entry in the translation table shall this packet be translated.

The VFR helps here. Although it does not defragment whole packets, it still allows to keep track of several fragments that constitute a single original packet, and deal with them as if they were a single large packet with all L4 information present.

Does this help a little? Please feel welcome to ask further!

Best regards,

Peter

Hi Peter,

Thanks for the reply - it's nice to hear I was on the right track! Can you clarify what VFR actually does? At the moment, I have a mental image of it forcing fragments to be buffered while it builds some kind of virtual picture of the full packet. Then once all of the fragements have been received, the router inspecting the virtual packet and forwarding the fragments on to the appropriate inside host.

Thanks,

Barry

Hello Barry,

The VFR is a generic mechanism in Cisco IOS that allows to treat all fragments of a single IP packet as if the packet was continuous and unfragmented.

If a packet is fragmented, several issues arise from the loss of L4 information in all but the first fragment. You already tackled the problem with PAT: without the information about the transport protocol and port, it is impossible to correctly associate an IP fragment with an appropriate translation entry in the translation table. Another very visible problem arises with ACLs: any ACL entries that perform matching on transport protocol, L4 ports, flags or other data usually inferrable only from the entire packet are not effective on second, third, etc., last fragment. That means that an ACL rule that permits, say, communication with a HTTP server (destination port TCP/80) will not apply to any non-first fragments of a former IP packet destined to an HTTP server's TCP port 80, breaking this communication. In worse scenarios, the non-first fragments may even cause a security issue as they will not be matched by the same ACL entries as the first fragments, thereby possibly subverting the existing security policies.

The VFR solves this problem by creating a record about all fragmented packets passing through this router and storing just enough information to tell for each IP fragment what would be the complete L3+L4 header information. All fragments of the same IP packet share the same source/destination IP address, the same packet ID number, the same payload type and reasonable offsets. By storing the L3/L4 information from the first fragment, you can always tell to which first fragment does a particular non-first fragment belong, and then use the stored L3+L4 information in all necessary mechanisms like PAT or ACLs. The VFR does not really defragment IP packets, that would be hugely inefficient - it only stores information so that any non-first fragment can be attributed to the corresponding first fragment and its L3+L4 headers.

Does this help somewhat? Please feel welcome to ask further!

Best regards,

Peter

Hi Peter,

Yes that's cleared things up for me nicely so I've marked the question as answered. Thanks for your input!

Regards,

Barry

Hello Barry,

I am honored! Thank you! It has been a pleasure. I hope you'll pay us here a visit from time to time with new interesting topics.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: