I think an important thing to point out here is that this is completely unsupported by Microsoft. One of the key issues is that you are changing something other than the host portion of the URL (because the modified URL does not end in "/sub1"), and Alternate Access Mappings (AAM) are not designed for this kind of scenario. The result is that you will have problems with URLs in things like alert e-mails, RSS feeds and potentially some areas of the website itself e.g. Content Query Web Part (to pick one example).
Plan Alternate Access Mappings has this to say:
Some reverse proxy devices can modify the path of a request (the portion of the URL that comes after the hostname and port number) in such a way that a request sent by the user to http://www.contoso.com/sharepoint/default.aspx, for example, is forwarded to the Web server as http://sharepoint.perimeter.example.com/default.aspx. This is referred to as an asymmetrical path. Windows SharePoint Services 3.0 does not support asymmetrical paths. The path of the URL must be symmetrical between the public URL and the internal URL. In the preceding example, this means that the "/sharepoint/default.aspx" portion of the URL must not be modified by the reverse proxy device.
Whether the URL modification is done by a reverse proxy device or code, the support constraint applies.
I've also seen code-based URL-rewriting solutions which have a terrible impact on performance (due to having to parse/rewrite the output stream).