05-23-2012 12:55 AM
I will try different things to find an answer to the question I am going to ask, and if I find a result will post here:-
To create sub-interfaces on a Physical interfae is not a problem. All the tunnels work.
My question though is, can we create 2 tunnels connecting to a single sub-interface.
05-23-2012 01:36 AM
Could you please elaborate on this.
Do you want to make a single sub-interface as outgoing i/f for two tunnels ?
Do you want to bind two tunnel interfaces to same sub-interface ?
Bothe the above mentioned cases are possible.
However if you are trying to achieve something else, please let us know.
05-23-2012 02:12 AM
Okay, let's say we have the following physical interface:-
SSG140 - Corporate
We create a sub-interface on the physical and we call it:-
SSG140 - Corporate
On the SSG5 (Remote Office) we create:-
int ethernet0/0 - Untrust - Tunnel.1 (The remote end of this tunnel will be on SSG140 int Ethernet0/4.25 - as noted above).
Now, we have a second network that needs to be utilised as a dirty network, however, there are many sites and creating a new sub-interface on the SSG140 is not viable as we can only have 50 per physcical, so the idea was to have a second tunnel utilise the same sub-interface as the first tunnel, as shown below:-
SSG5 (Remote office) we want to create the following:-
1: New virtual router named "Dirty-VR"
2: Create a new tunnel
3: Bind interfaces to new VR
4: Utilise ethernet0/4.25 as the end point for this second tunnel (so that we do not have to create another sub-interface on the SSg140)
So, the tunnel has to go out via the bound interface, as e0/0 is in the untrust zone, then we have to use e0/4 on the SSG5 (we will, after testing. assign it ot bgroup1 and assign e0/1 through to e0/4 to this group).
So, ethernet0/4 (SSG5) ------ > ethernet0/4.25 (SSG140)
The problem we are experiencing trying to achieve this is that when 1 tunnel comes up, the other tunnel drops.
I cannot find any documentation anywhere regarding the setup for this and even if its possible as the same gateway has to be used surely, due to the IKE phase 1 of IPSec.
Any help would be greatly appreciated.
05-23-2012 05:22 AM
05-23-2012 06:53 AM
Okay, getting there. The testing is getting a bit better now.
It would appear the old engineer had not entered the Proxy ID's on the original sites and everyone assumed it was just working. Upon checking we found there was no other site where they had got this working, so, we decided to:-
AutoIKE (For phase 1) - Made sure "Proxy-ID" was enabled and then set the local LAN and remote (Peer) LAN networks and tried again.
Voila.... we now have showing as "UP" 2 tunnels on the same sub-interface. However, we still have one more issue we have to iron out.... although both tunnels say they are "UP", we ping from one to a device the far end and it is successful, we see the traffic as we should, however, when pinging from the other tunnel, it is failing, but the good news is, that in the log files we see the ICMP packets at the far end, so we know the tunnel is working.
My guess is that the routing on the SSG140 is not correct somehow, so I really need to investigate.
Thanks for the help guys and will post the results here, it may help someone who has the same issues....
05-23-2012 07:43 AM
That's a good news ....
About the ping issue, you can run ' debug flow basic' with filters simultaneously on both sites and then try pinging. This should tell you the reason for ping failures.
05-24-2012 01:11 AM
Okay, thank you for the info.
We now have both tunnels working as they should.
I have to hold my head in shame now though, because, yes, you guessed it, the problem was the good ole "Typo".
We were testing on 192.168.96.0 / 24 network, and although we spent a good few hours looking at this, I noticed last thing yesterday that the source port was labelled as "192.168.69.xxx" ..... oh dear 69 instead of 96..... So, the route back was through a different interface onto a seperate network..... changed the address and hey presto... all working.
Thank you so much for your help guys...... very much appreciated.