07-27-2012 01:55 AM
I've been looking at this VPN setup, 1 of which my colleagues set up but was having troubles with. But I can't seem to figure out exactly what's wrong. But I feel it must have to do with the routing, however I do have the routes added to send traffic for the remote local networks over the st0.0 interfaces.
So in summary:
I've attached both configs of both devices so you at least have all the info, hopefully one of you can point me to the solution.
Solved! Go to Solution.
07-27-2012 09:21 AM
You have the st.0 interface in your trust zone, plus a few other errors.
I have attached one end of working SRX config.
07-30-2012 02:18 AM
I have built up Site to Site vpn's before with srx's and replicated the steps used in those configs and have always used the st0.0 interface in the trust-zone.
But I have moved it over to a separate zone now and nothing's changed. I think the problem is probably in the routing table somehow as they can reach the hosts locally or that are directly connected, but not beyond that.
However testing the routes does show them to work as they will send the traffic for the remote local network over the st0.0 interface.
You point out that there are other errors as well, I've compared the configs to previous ones that work just fine and yours and can't really find huge differences, but I might be reading over them.
Could you elaborate or point me in the right direction?
07-30-2012 04:54 AM - edited 07-30-2012 05:04 AM
Is there a reason you have ip-addresses on your tunnel interfaces? If not, remove them and try again.
Else you could always configure flow traceoptions.
Also - unrelated to the issue you're facing, I'd change aggressive mode to main mode, and like john mentioned, put st0's in separate zones, gives a lot cleaner/easier configuration imo.
07-30-2012 06:23 AM
I had added the ip's on the st0.0 interfaces because I had read on this forum somewhere that that fixed it for someone in my situation. Those weren't in my default config which I tend(ed) to use.
Removing them again has not yielded any progress. So I guess I'm back to traceoptions then, which I haven't been able to get too much useful information out of thus far.
as for the st interface being in the trust-zone, I've moved it to it's own zone on both devices.
07-30-2012 06:31 AM
07-30-2012 10:18 AM
07-31-2012 08:53 AM - edited 07-31-2012 08:54 AM
A couple notes:
IP addresses on st0 interfaces aren't required for point-to-point vpns, point-to-multipoint need an IP.
However, I generally don't use an IP from my vlan subnet on a tunnel. Pick something like a /30 that is not in the subnet.
Router A ----------------------------------------------
172.16.0.0/24 192.168.0.1/30 ---st0--- 192.168.0.2/30 -- 172.16.1.0/24
Then your routes would point the the opposite side 192 address.
As for placing the st0 interfaces in the trust zone, not a problem at all, just can trip up policy sometimes, so generally they are put in a vpn zone or the untrust zone to keep it logical.
Let me know if any of that helps
Also, the main or aggressive mode doesn't matter in this case. If main mode is just an additional security level, but if one peer is dynamic, aggressive is required.
08-01-2012 07:46 AM
I normally don't use IP's either and as I've said I've reverted back to having the st0.0 without an IP on both devices.
I've not switched the mode from aggressive to main as I can do that later and the tunnel is up, that's not the problem.
email@example.com> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 4891439 UP c1911570ef2b6e61 77239aed0a7c245d Aggressive a.b.c.d firstname.lastname@example.org> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway <131073 ESP:3des/sha1 34dd7097 2497/ unlim - root 500 a.b.c.d >131073 ESP:3des/sha1 7ed273e3 2497/ unlim - root 500 a.b.c.d
This is the interface information of st0.0 now:
email@example.com> show interfaces st0.0 Logical interface st0.0 (Index 79) (SNMP ifIndex 532) Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel Input packets : 5566 Output packets: 5975 Security: Zone: vpn Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp Protocol inet, MTU: 9192 Flags: Sendbcast-pkt-to-re
Showing the route table:
firstname.lastname@example.org> show route inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 6d 22:46:36 > to 22.214.171.124 via fe-0/0/0.0 126.96.36.199/24 *[Direct/0] 6d 22:46:36 > via fe-0/0/0.0 188.8.131.52/32 *[Local/0] 6d 23:28:24 Local via fe-0/0/0.0 172.16.0.0/24 *[Static/5] 6d 02:10:37 > via st0.0 172.16.0.2/32 *[Static/5] 6d 00:44:09 > via st0.0 172.16.1.0/24 *[Direct/0] 5d 22:49:53 > via vlan.0 172.16.1.1/32 *[Local/0] 6d 23:28:33 Local via vlan.0
Pretty sure the route is fine since it sends the traffic over the tunnel. Also shows the local subnet of 172.16.1.0/24 to be directly connected.. so any traffic for that network coming over the tunnel should reach it right?
08-01-2012 01:24 PM
Can you initiate some traffic between 172.16.0.x and 172.16.1.y and post
an output of "show security flow session" (for these sessions only,
you can filter by source-prefix and destination-prefix).
From this output it will be seen if you get any reply packets. Also
you have nat configured in your original configs, and you are doing
NAT to the interface address. This should not be breaking things, but
in your case you have (or had) different subnets on st0.0 interfaces
on differen sides, which will cause an issue (SRXs don't know
other's st0.0 subnet, to which NAT is made).
However I don't know why it is still not working after moving st0 to
other zone because NAT shouldn't be applied now. So please post the
output with sec flow sessions and your new configs also, if possible.