First of all, let's be more exact about what your indexes look like (it always helps to post the DDL instead of speaking it out in terms of english to eliminate any ambiguity). From what you describe, I'll assume the indexes are:
create index <somename> on tab1(id,c1,c2)
create index <somename> on tab2(id,c3)
Secondly, the order of your search predicates does NOT matter to the optimizer. And forcing index usage is NOT a good idea (99% of the time) and can lead to suboptimal performance (there is a reason the optimizer chooses the plan it does).
Now, if the join method chosen is a NESTED LOOP (outer table scanned for qualifying rows, then those rows joined to inner table applying JOIN ON predicate and/or search predicates), then the order in which tables are joined has to be determined. The manuals go into detail about this, but in chosing which table is the outer table, let's talk about index selection. What index on either table would you use to select rows given the search predicates (the WHERE clause only, the JOIN ON clause can't be applied to the outer table)?
For tab1, we have a search on c1 and c2 columns. Those are non-leading columns of the index. For tab2, the search is on c3. That is a non-leading column on tab2. So these indexes don't look particularly useful for the outer table. That means a table scan of every row looking for matches. Then, for each match, using the index on the inner table to satisfy both the JOIN ON predicate and search (WHERE) predicate.
For other join methods that might be considered (particularly MERGE JOIN), if both indexes are clustered indexes, a merge operation would take place as per the manuals which I won't go into here.
If, (c2, c1) together are very selective the I would suggest an index on tab1(c2,c1,id). If tab2.c3 is a very selective (unique) predicate, I would suggest index on tab2(c3,id). In either and/or both cases, the outer table of a NESTED LOOP join would have search predicates that could be applied reducing the total number of rows processed(evaluated) in the outer table with a supporting index supporting both search and join predicates on inner table.
Try all combinations using some test cases and measuring logical reads (set statistics io on) to find which one performs best for you.